similar to: [LLVMdev] Unable to link in X86AsmParser.cpp into lli

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

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

On 5/14/2012 9:18 AM, Jim Grosbach wrote: > > On May 14, 2012, at 9:07 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> I was able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). >>

On May 14, 2012, at 9:42 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > > On 5/14/2012 9:18 AM, Jim Grosbach wrote: >> >> On May 14, 2012, at 9:07 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: >> >>> I was able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external

Hi All, I built the binaries from the 3.1 final tag (http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_31/final/ etc) as below: > ../llvm/configure --enable-targets=host-only --prefix=/local/mnt/workspace/ashoknn/crd/neo/llvmsvn/build/bin > make install I notice that I can compile a program using clang as below: > ashoknn at

Resending, can somebody please help? On 5/16/2012 2:47 PM, Ashok Nalkund wrote: > Hi All, > I built the binaries from the 3.1 final tag > (http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_31/final/ etc) as below: > >> ../llvm/configure --enable-targets=host-only --prefix=/local/mnt/workspace/ashoknn/crd/neo/llvmsvn/build/bin >> make install > > I notice that

Are you intending to try to link? That error message isn't coming from clang, but from /usr/bin/ld. If you just want the bitcode for the one source file, you need to pass "-c" as well, just like if you want an object file. -Jim On May 16, 2012, at 5:39 PM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > Resending, can somebody please help? > > On 5/16/2012 2:47 PM,

MY BAD (in caps)...really sorry to have bothered. I was thinking of -S -E options but forgot the -c option. clang -c -emit-llvm test.c lli test.o both work fine :). Thanks, ashok On 5/16/2012 5:45 PM, Jim Grosbach wrote: > Are you intending to try to link? That error message isn't coming from clang, but from /usr/bin/ld. If you just want the bitcode for the one source file, you need to

On May 14, 2012, at 9:07 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > I was able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). > > Then I hda to disable the following code in

I was able to get past the error by calling InitializeNativeTargetAsmParser() in my code. Now I have a failure in resolving external libraries, so looking into that (recompiled with --enable-ffi but I now get an error LLVMgold.so not found). Then I hda to disable the following code in lib/Target/X86/X86CodeEmitter.cpp: > case TargetOpcode::INLINEASM: > // We allow inline

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:

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. >>> >> >> Do I need to enable anything at configure, my configure looks like this: >>> ../llvm/configure --enable-libffi --enable-targets=host-only

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

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. >>>> >>> >>> Do I need to enable anything at configure, my

Hey: I spent sometime debugging this, it seems like editing ``llvm/tools/opt.cpp`` and move ``cl::ParseCommandLineOptions(argc, argv, "llvm .bc -> .bc modular optimizer and analysis printer\n");`` to the beginning of main() solved it for me. I'm not sure if this is a bug on LLVM side Zhang ------------------ Original ------------------ From: "Viktor Was BSc via

The fundamental problem here is that opt doesn’t use ExecutionEngine (because it has no need to), so trying to use ExecutionEngine (or any other bit of llvm that opt doesn’t use for that matter) in an opt plugin isn’t going to work. The solution I’d go with would be to build llvm with shared libraries (use –DBUILD_SHARED_LIBS=ON on the cmake command) then link the plugin against ExecutionEngine.

So, I'm setting about trying to fix the layering of TargetSelect.h (& TargetRegistry.h, but haven't really got to its issues yet). The issues can be demonstrated fairly plainly by moving any/all of TargetSelect.h's functions out of line. Pretty much all programs in LLVM fail to link because libSupport doesn't actually depend on all the targets, quite the opposite in fact. So,

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 Apr 8, 2013, at 2:55 PM, "Robinson, Paul" <Paul_Robinson at playstation.sony.com> wrote: I keep seeing "this is a layering violation" comments on the lists. > While there are a few llvm.org pages that mention layers in passing, > there is nothing (that I've found) actually specifying the layers. > Trying to infer the layering from the code is tedious and