similar to: [LLVMdev] Problem while building llvm

Hi, all I come across the problem when building llvm. The errors are as follows ... etJITInfo&, llvm::JITMemoryManager*, llvm::CodeGenOpt::Level, bool)': : undefined reference to `__register_frame' collect2: ld returned 1 exit status make[2]: *** [/home/lishengmei/llvm-2.6/Release/bin/lli] Error 1 make[2]: Leaving directory `/home/lishengmei/llvm-2.6/tools/lli'

Hi, all I use llvm-gcc -O4 to compile SPEC 2000, some benchmarks can't be built successfully, such as 164.gzip, 175.vpr etc. The error messages are as follows. .. zh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip bits.o: file not recognized: File format not recognized collect2: ld returned 1 exit status specmake: *** [gzip] Error 1 specmake options 2> options.err |

On 2009-12-23 08:22, Li Shengmei wrote: > > Hi, all > > I use llvm-gcc –O4 to compile SPEC 2000, some benchmarks > can’t be built successfully, such as 164.gzip, 175.vpr etc. > > The error messages are as follows. > > > > …… > > zh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip > > bits.o: file not recognized: File format not recognized

Hi, I want to know what benchmarks can LLVM compile and run successfully. Such as SPEC CPU2000, SPEC CPU2006 or other benchmarks. Thanks Shengmei -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091221/ed70efce/attachment.html>

On Sun, Dec 20, 2009 at 7:06 PM, Li Shengmei <lism03 at gmail.com> wrote: > Hi, > >          I want to know what benchmarks can LLVM compile and run > successfully. > > Such as SPEC CPU2000, SPEC CPU2006 or other benchmarks. llvm-gcc can compile essentially anything in C/C++. -Eli

Hi, all We want to learn the IR of LLVM. Are there any information or documents you can suggest? Or any suggestions are welcome. Thanks Shengmei -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091211/0a788413/attachment.html>

Hi, > / : undefined reference to `__register_frame' / this is defined in libgcc on most platforms and is used for registering exception handling frames. LLVM's JIT makes use of it on some platforms. What version of gcc are you using? Ciao, Duncan.

Thanks, sands My gcc version is 3.4.6. Any problems? Shengmei ---------------- Hi, > / : undefined reference to `__register_frame' / this is defined in libgcc on most platforms and is used for registering exception handling frames. LLVM's JIT makes use of it on some platforms. What version of gcc are you using? Ciao, Duncan.

Hi, I am new to Clang. There is a warning when I use clang $llvmc -clang test.c "./bin/ld: warning: cannot find entry symbol mit-llvm-bc; defaulting to 00000000004003c0 llc: bitcode didn't read correctly." When I use lli to execute the test.bc as $lli test. bc The error message is "lli: error loading program 'test.bc': Bitcode stream should be a

I found the following problem when I try to debug "target does not support mc emission" in linux (the same code executes OK in windows): Below is a snippet extracted from this method, if (UseMCJIT && ExecutionEngine::MCJITCtor) { ExecutionEngine *EE = ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, OptLevel,

Hi Brian, On 29/07/13 23:42, Brian Herman wrote: > I got the following error while compiling llvm and clang under cygwin. > > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): > undefined reference to `__register_frame' I register_frame is used to enable the debugger (gdb) to

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

Nobody give comments on this? Is the source to source transformation of LLVM robust enough? Thanks in advance. Shengmei _____ Problems of source to source transformation of LLVM Hi, I did experiments of the source transformation of LLVM on SPEC2000 C programs. But I found most benchmarks can't be transformed from source to source successfully. The steps are as

Hi Andrew, Andrew Haley wrote: > Here's my problem, which I raised on IRC: > > JIT::getPointerToFunction gets the address of the start of a function. > But how do I find out where the end of the function is? I need this > to register the function for profiling. > > varth said: aph, you need to intercept the "endFunctionBody" call on > the memory manager, it

I got the following error while compiling llvm and clang under cygwin. /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): undefined reference to `__register_frame'

Nicolas Geoffray wrote: > Hi Andrew, > > Andrew Haley wrote: >> Here's my problem, which I raised on IRC: >> >> JIT::getPointerToFunction gets the address of the start of a function. >> But how do I find out where the end of the function is? I need this >> to register the function for profiling. >> >> varth said: aph, you need to intercept

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the

On Tue, Oct 6, 2009 at 5:49 PM, Reid Kleckner <rnk at mit.edu> wrote: >> Also, the null pointer is coming from a call to JCE->allocateSpace(). >> This is a virtual function; I'm trying to discover what subclass it >> is. > > So, there's JITEmitter::allocateSpace which overrides > JITCodeEmitter::allocateSpace(), but *most* of the time it just calls >

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons