similar to: [LLVMdev] Assertion when loading bitcode

>>>>> I am using GCC 4.3.2 ( Debian 4.3.2-1.1) on x86. I will try out a different compiler. I tried out Sourcery G++ Lite 2009q1-203 (GCC 4.3.3). I still can't get lli to run. This time the error is like this: 0 lli 0x00651128 1 lli 0x00651960 2 libc.so.6 0x40212600 __default_sa_restorer_v1 + 0 3 lli 0x00282ef0 4 lli 0x00283cec

>> I can cross-compile LLVM-2.5 to ARM and run lli on a simulator in debug >> mode . However, when I now compile with optimization enabled, lli >> triggers an assertion when loading bitcode files. The assertion looks >> like this : >are you not able to use a more recent version of LLVM like LLVM-2.7? I tried out LLVM-2.7. It also triggers an assertion. This

>>> I can cross-compile LLVM-2.5 to ARM and run lli on a simulator in debug >>> mode . However, when I now compile with optimization enabled, lli >>> triggers an assertion when loading bitcode files. The assertion looks >>> like this : > >>are you not able to use a more recent version of LLVM like LLVM-2.7? > > > I tried out LLVM-2.7.

Hello Everyone, I can cross-compile LLVM-2.5 to ARM and run lli on a simulator in debug mode . However, when I now compile with optimization enabled, lli triggers an assertion when loading bitcode files. The assertion looks like this : lli: /home/Virement/llvm/llvm-2.5-linux/include/llvm/Support/Casting.h:199: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X

Ping? Still looking for advice in figuring out how and why my generated code is causing lli to crash... Talin wrote: > I've been using lli to do most of my unit tests for the compiler that > I'm writing. However, when I get a test that crashes, its difficult to > find which instruction it was that caused the crash. I tried running > bugpoint, but it didn't seem to work

Hi, I am trying to reduce what I believe to be a miscompilation bug. Running lli on my bitcode file causes a segmentation fault. However, running bugpoint as bugpoint file.bc gives me the following errors, /tmp/ccAdmNqH.o: In function `_ZL17bus_error_handleriP7siginfoPv': bugpoint-test-program.bc-Vega5s.cbe.c:(.text+0x1b4e1): undefined reference to `std::cerr' /tmp/ccAdmNqH.o: In

I've been using lli to do most of my unit tests for the compiler that I'm writing. However, when I get a test that crashes, its difficult to find which instruction it was that caused the crash. I tried running bugpoint, but it didn't seem to work for me, and upon reading the documentation, it seems to be intended for a different purpose than finding bugs in my source program; It

Works for me: [jhereg:~/tmp] echristo% /Volumes/Data/builds/build-llvm/Debug+Asserts/bin/clang -S -emit-llvm foo.cpp [jhereg:~/tmp] echristo% lli foo.s testing [jhereg:~/tmp] echristo% llvm-gcc -S -emit-llvm foo.cpp [jhereg:~/tmp] echristo% lli foo.s testing the first is using top of tree clang. The second is using an llvm-gcc on my OS. What versions are you using? -eric On Feb 6, 2012, at

Resending, any pointers? I demangled the symbol and it turns out to be: std::__1::locale::use_facet(std::__1::locale::id&) const tia, ashok On 5/19/2012 9:41 PM, Ashok Nalkund wrote: > Hi, > LLVM/Clang version: 3.2svn (r156975). I have a bitcode file that I'm > trying to load/execute using lli as below but it reports an error about > unresolved symbol: >> LLVM

Hi, LLVM/Clang version: 3.2svn (r156975). I have a bitcode file that I'm trying to load/execute using lli as below but it reports an error about unresolved symbol: > LLVM ERROR: Program used external function '_ZNKSt3__16locale9use_facetERNS0_2idE' which could not be resolved! > lli: /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/llvm/lib/Support/ThreadLocal.cpp:54:

Hi Eric, Here's the C code (example.c): include <stdio.h> int main() { printf("testing\n"); } Here's the LLVM IR (from llvm-gcc): ModuleID = 'example.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple =

On Fri, Jun 4, 2010 at 1:09 AM, Nehal Gandhi <nbg2k7 at gmail.com> wrote: > Hi Eli, > > I have attached a tar file containing Pass (ConditionPass.cpp), External > function (PrintRes.cpp) and test program (try.c). I use command chain as > describe in previous mail. Can you just attach the final program.bc you pass to lli? I don't know how to build a plugin off the top of

Ashok Nalkund wrote: > Resending, any pointers? I demangled the symbol and it turns out to be: > std::__1::locale::use_facet(std::__1::locale::id&) const My guess is that you've got a .bc file produced on a mac using libc++ (hence the ::_1 part) and you're trying to run it on linux with libstdc++ (which doesn't use inline namespaces, the '::_1::' part). That

On Saturday 11 of February 2012 14:29:10 Paweł Sikora wrote: > Hi, > > afaics in manuals the llvm-{link,ld} tools only can merge bitcode files > into one bigger piece which looks like a static-linking from the c/c++ world. > i'm wondering is it any possibility to link bitcode elements dynamically > in the same way as e.g. c#/msil assemblies? static linking into one

Hi Xiaolong, > As Duncan described, "lli -load=libstdc++.dylib ..." works. I, > however, encounted an "Illegal instruction" message, while I was > trying to interpret a large program. are you using the interpreter or the JIT? So, does lli have a debug switch > for dumping out the details for errors? > > Using llc is not that simple, and I have not gotten

Hi Nick, > Fundamentally the issue is that the system linker is supposed to define > __dso_handle when linking, but since there is no system linker between > your build of the .bc files and running lli, nobody has defined it. > > It seems reasonable to me that lli should define __dso_handle if it's > declared in the module. > > You could module tools/lli/lli.cpp to add

Alkis Evlogimenos wrote: >Is there a chance you can try cvs? I would be interested to >get a simplified test case where the allocator breaks. A lot of >improvements went into the x86 backend since 1.2 and we currently have >no test cases where the allocator breaks today. > > I updated and recompiled and the error is still there. It turns out that I cannot use the bugpoint

Hello, I am trying to run 32-bit bitcode with lli built with 64bit configuration. But it always crashes without any messages when I try to run 32bit bitcode. If anyone experienced same situation and have some clues to resolve, can you please share? FYI, I am using lli in llvm-3.0 Thanks, Taemin -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, For the very simple example below, I get *Unknown instruction error from lli and llvm-dis*, while* llc does not print anything*. Not sure what is that I am missing here. My llvm-gcc version is i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) 1-39-155-188:pastebin Babai$ cat example.c #include <stdio.h> void hello() {

On Fri, Jun 4, 2010 at 12:09 AM, Nehal Gandhi <nbg2k7 at gmail.com> wrote: > On Thu, Jun 3, 2010 at 10:45 PM, Nehal Gandhi <nbg2k7 at gmail.com> wrote: >>> Hi Eli, >>> >>> Thanks for that. Rookie mistake on my side. It solves the linking issue. >>> However, it was not the main problem. The problem is when I execute the >>> linked file (