similar to: [LLVMdev] lli should link with selectiondag

Hi, Using the trunk of svn. I'm trying to get inline-asm working on X86. So I added call to: > InitializeNativeTargetAsmParser() during initialization. However, this causes a linking error: > llvm[2]: Linking Debug+Asserts executable lli > /local/mnt/workspace/ashoknn/crd/neo/llvm/proto/llvmsvn/build/tools/lli/Debug+Asserts/lli.o: In function

On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >> >> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can you step through EngineBuilder::create() and see what's happening there? >> >> -Jim

On May 14, 2012, at 11:12 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >>> >>> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can

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

Following simple program gives different answers when compiling with GCC (4.8.4) and ToT Clang: $ cat builtin_fmodf_bugpoint.cpp #include <cstdio> int main(int argc, char** argv) { const float a = 1.0f; const float b = 0.1f; printf("%f mod %f = %f\n", a, b, __builtin_fmodf(a, b)); return 0; } $ g++ -o builtin_fmodf_bugpoint_gcc builtin_fmodf_bugpoint.cpp $

On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>

Hi, In my experiments, I need to disable several linking optimizations. However, bzip2, vortex and eon failed if "-disable-opt" was passed to gccld. I tried the out-of-box llvm and the building process provided by llvm-test. The same problem was observed, when I specified EXTRA_LINKTIME_OPT_FLAGS = -disable-opt on Makefile.program and simplied typed "make" under

On Oct 18, 2009, at 6:32 PM, Eric Brunstad wrote: > Hi, > > Is it possible to run Objective-C code in lli? lli does not seem to > want to load Foundation.framework. It is definitely possible, but we're not there yet. LLI would have to know about objective-c metadata to register it properly with the runtime. This is important for things like classes etc. This isn't

Hi, Is it possible to run Objective-C code in lli? lli does not seem to want to load Foundation.framework. Please see below. Thanks, Eric Brunstad #import <Foundation/Foundation.h> int main(int argc, char *argv[]) { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; NSLog(@"test!"); [pool drain]; return EXIT_SUCCESS; } cmu-351714:llvm-2.5 ericbrunstad$

Hi, What would be an estimate for the amount of work required to implement this? Where would I get started if I were to implement it? My goal is to run Objective-C programs in the interpreter so I can provide an application-sandbox by disallowing the invocation of certain C-functions and also by disallowing the invocation of certain Objective-C methods. Thanks, Eric On Oct 19, 2009,

On Wed, Dec 30, 2009 at 7:53 PM, Heming Cui <heming at cs.columbia.edu> wrote: > Dear all, >      I hope you enjoy your christmas! Recently I started to play lli with > bc. I found that the lli only calls the main() function in bc file and then > does nothing before the main() function returns, which means that the > JIT::runFunction() function is involved only once with the

Hi all, I am facing new problem with lli now. I am having a sample code in which I am doing malloc for two variables. If I compile the code with normal gcc the program runs without any warning of any sorts. If I compile the program to convert it into a bytecode file and then run it through lli it segfaults and the program aborts. This is the stack trace after execution. lli((anonymous

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

Jello Juan, The interpreter is quite useless in its current state. Try using a JIT compiler for you computer from the lli command and it should work. --Sam > >From: Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com> >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >Sent: Thursday, June 25, 2009 1:04:17 PM >Subject: [LLVMdev] Problems with lli

Hi, What is mklib trying to do with lli.exe.exp? However, lli.exe gets linked anyway. -------------- llvm[2]: Linking Debug executable lli /C/projects/build/MinGW/llvm-1-1/mklib: /C/projects/build/MinGW/llvm-1-1/Debug/bin/.libs//C/projects/build/MinGW/llvm-1-1/Debug/bin/lli.exe.exp: No such file or directory llvm[2]: ======= Finished Linking Debug Executable lli -------------- Henrik.

Dear all, I hope you enjoy your christmas! Recently I started to play lli with bc. I found that the lli only calls the main() function in bc file and then does nothing before the main() function returns, which means that the JIT::runFunction() function is involved only once with the main() function in bc file. If this was true, then lli does not have any control to the execution of program.

Hello, I just install the new newest version of LLVM. When I ran the hello.c example I got the below message. Somebody has an idea what is wrong? The problem is just with lli, the other commands worked as I expected. ********************** :~/LLVM/my-test$ lli hello.bc Tried to execute an unknown external function: i32 (i8*)* puts 0 lli 0x0861fab8 Stack dump: 0. Program arguments: lli

Hi, Is it normal/expected for `llc` to support a different set of targets than `lli`? I have a hello.ll on which this works: $ llc -mtriple=armv7a-linux-gnueabihf hello.ll # OK, generates hello.s But this doesn't: $ lli -mtriple=armv7a-linux-gnueabihf hello.ll # lli: error creating EE: No available targets are compatible with this triple, see -version for the available targets. I'm

Linking lli debug executable (without symbols) /mounts/zion/disks/0/localhome/pmeredit/llvm/lib/Debug/lli-interpreter.o(.te xt+0x643a): In function `llvm::Interpreter::callExternalFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&)': /localhome/pmeredit/llvm/lib/ExecutionEngine/Interpreter/ExternalFunctions.c pp:98: undefined

I get the following error when I try to run arm lli on QEMU: lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed. 0 lli 0x006abbfc Stack dump: 0.