similar to: [LLVMdev] JIT "Error: Recursive compilation detected!" when lazily compiling one function at a time

Hello, Platform is RHEL5, GCC 4.2.4, x86-32, and LLVM/LLVM-GCC from subversion (yesterday evening). I'm compiling C code into bitcode, and then executing the bitcode using the JIT compiler (lli). I've managed to reproduce a problem when multiple signals go off around the same time. A sample program is below. The result is the "recursive compilation detected" JIT compiler

Hi James, > want to send us your testcase code? Then we can give it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > want to send us your testcase code? Then we can give it a whirl. >> >> >> Test code is at http://giantblob.com/ehtest.tar.gz >> >> Thanks for the help. I apologize in advance if it turns out I'm doing >> something stupid! >> > > I hope you realise that by

Hi all, I need to run c++ prgrams using lli. However, I find lli cannot handle the alias instruction correctly. Following is an example: ------------ example.cc ------------- #include <iostream> using namespace std; class cls { public: cls(); ~cls(); }; cls::cls() { cout << "constructor" << endl; }; cls::~cls() { cout <<

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> want to send us your testcase code? Then we can give it a whirl. >>> >>> >>> Test code is at http://giantblob.com/ehtest.tar.gz >>> >>> Thanks for the help. I apologize in

Hi James, Note that the wiki example is a manual JIT example that works directly with the C++ APIs. As you know, no LLVM tools are used, just LLVM libraries. I say this to point out, that in the example, the exception mechanism is under the complete control of the developer moded by the LLVM libraries. In my mind a different example/different doc. would be needed to explain how a bit code

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Hi James, > > Note that the wiki example is a manual JIT example that works directly with > the C++ APIs. As you know, no LLVM tools are used, > just LLVM libraries. I say this to point out, that in the example, the > exception mechanism is under the complete control of the > developer moded by the LLVM libraries.

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

Hey, I have a situation where in I need to intercept a call to a particular function and return a pointer to a separate implementation of that function using JIT. The scenario is like this: 1. A test code or client code calls a function A() for which a dummy implementation is provided in a library which the test code/client links with during compilation. 2. I create the .bc using -emit-llvm and

Hi Everyone, When I compile a program with clang with debug symbols enabled and I try to run it using the JIT (lli) I get the following error message. I am running on Lion (10.7.4). Thanks. George >> pseudo instructions should be removed before code emission UNREACHABLE executed at /Users/JD/Software/llvm3.1/llvm-3.1.src/lib/Target/X86/X86CodeEmitter.cpp:736! 0 lli

Hi Everyone, I've managed to create a small example that reproduces the error that I'm seeing when generating code, or running the interpreter: ----------------------------------------------------------------------- @llvm_gc_root_chain = global i8* null declare i8* @malloc(i32) declare void @llvm.gcroot(i8**, i8*) nounwind define i32 @main() gc "shadow-stack" { %value =

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

Hi everyone, I compiled grep with llvm-3.4(because consumer tool uses llvm3.4 bit code) and generate bit-code for this. When I am running with lli output is pseudo instructions should be removed before code emission UNREACHABLE executed at /home/awanish/llvm/llvm-3.4.2/lib/Target/X86/X86CodeEmitter.cpp:1176! 0 libLLVM-3.4.so 0x00007f1250f655d5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1

Hi, I've been implementing a compiler that targets LLVM, and was looking into using the shadow-stack gc strategy. Currently, I build the runtime with clang (using -emit-llvm), and then link that with the LLVM bitcode output from my compiler using llvm-ld. This works fine without the gc strategy annotations and use of the llvm.gcroot intrinsic, but adding them causes some odd behavior: the

>>>>> 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

Hi, I've trying to test a pass with a C version of the 171.swim SPECfp benchmark. If I run llvm-gcc on the C files, I can generate a functioning executable. However, if I use llvm-gcc with -emit-llvm, then run lli on the resulting bitcode, I get the following error: lli: /x/jeffhao/llvm/llvm-2.4/lib/ExecutionEngine/JIT/JIT.cpp:467: void llvm::JIT::runJITOnFunction(llvm::Function*):

Hi, I've trying to test a pass with a C version of the 171.swim SPECfp benchmark. If I run llvm-gcc on the C files, I can generate a functioning executable. However, if I use llvm-gcc with -emit-llvm, then run lli on the resulting bitcode, I get the following error: lli: /x/jeffhao/llvm/llvm-2.4/lib/ExecutionEngine/JIT/JIT.cpp:467: void llvm::JIT::runJITOnFunction(llvm::Function*):

I edit two files named test.h,test.cpp as follow: ///////////////test.h//////////////////////////////////////////////////////////////// class TestClass { private: int fTotal; public: TestClass(); ~TestClass(); }; ///////////test.cpp///////////////////////////////////////////////////////////////////////////// #include "test.h" TestClass::TestClass() { fTotal = 2; }

Hi Sam, I've not actually gotten to the linking process with my runtime, as I've compiled it with clang -emit-llvm -c, and then archived it with llvm-ar and llvm-ranlib. I'm also not producing a GC plugin, as I'm using the builtin "shadow-stack" strategy. My current build process looks like this: 1. build the compiler 2. build the runtime using clang -emit-llvm -c