similar to: [LLVMdev] [llvm-commits] [llvm] r160610 - /llvm/trunk/lib/ExecutionEngine/TargetSelect.cpp

Hi Takumi, I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32? I'm modifying the MCJIT tests so that they will

2012/9/13 Kaylor, Andrew <andrew.kaylor at intel.com>: > I'm a bit confused as to what is supposed to happen in the cross building scenarios. For instance, if host=x86_64-linux and target=i686-mingw32, what should the MCJIT tests do? Should they be suppressed because the architectures don't match? If so, what about the case where host=x86_64-linux and target=x86_64-mingw32?

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,

On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Alternatively we can really say this header is a textual header - it's > included generally only once in a whole program, the functions are called > only once, etc. Though that does seem a little unfortunate on principle but > not much practical problem with it, I think.

Hi all, Writing my own LLVM client I've noticed a potential null pointer dereference in EngineBuilder::selectTarget. The class has an optional pointer to the ErrorStr, which can be initialzied through setErrorStr() method. Although, it's strictly optional, selectTarget doesn't verify its value before assignment. Please find patch for branch release_31, revision 155051 attached. -

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function

Could you guys clarify one thing for me? It sounds like the idea is that the current model of configuring the selection of targets would go away, to be replaced by an all-or-native-only switch. Sometimes I like to configure X86+ARM because that reduces rebuild time and still gets me the vast majority of debug-info tests. Or maybe you're using "all" as a shorthand for "all

On Tue, Nov 28, 2017 at 11:27 AM Reid Kleckner <rnk at google.com> wrote: > On Tue, Nov 28, 2017 at 11:23 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Alternatively we can really say this header is a textual header - it's >> included generally only once in a whole program, the functions are called >> only once, etc. Though

My only alternate ideas are: a) To heck with this only a single target thing. b) Autogenerate the entire file and library support as part of the build and have the various functions "defined" in the appropriate libraries. I don't really think a) is feasible, and b) is a bit of a stretch too. :\ -eric On Mon, Dec 4, 2017 at 5:37 PM David Blaikie <dblaikie at gmail.com>

Hi Yury, No need for the "{" "}" since it's a single statement in the compound statement. Other than that minor style detail, this looks fine assuming it applies cleanly to trunk. Do you have commit access? Regards, -Jim On May 9, 2012, at 3:40 PM, Yury Mikhaylov wrote: > Hi all, > > Writing my own LLVM client I've noticed a potential null pointer

Thank you for your response Jim. As of revision 153342 it applies properly to trunk. No, unfortunately I don't have access, would you please commit it for me? Thanks, Yury On Wed, May 9, 2012 at 4:37 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Yury, > > No need for the "{" "}" since it's a single statement in the compound > statement.

Hello, When I try to create execution engine I do get "*Interpreter has not been linked in.*" error and EngineBuilder returns NULL. Here is the line I use to create execution engine: auto executionEngine = llvm::EngineBuilder(std::move(m_module)).setErrorStr(&error).create(); Here are all headers I have included: #include "llvm/ADT/STLExtras.h" #include

Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow. Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows? -- lg > On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Larry, > > You're basically there, but you're hitting

Hello, Maybe my version (LLVM 2.5) is incomplete... now get this error: toy.cpp:11:38: error: llvm/Target/TargetSelect.h: No such file or directory How can I get this file? Regards, Juan Carlos On Wed, Jun 17, 2009 at 12:51 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > > > FWIW, I'm also suddenly experiencing

Hi, I want to use a function defined in c(++)-code from code generated by llvm. For this I use ExecutionEngine.addGlobalMapping(). I started with the JIT execution engine and everything worked, then I switched to the interpreter engine and it stopped working, but only if compiled on a Linux system. More precisely it works if I use llvm 3.8.1 + gcc (Linux) + JIT llvm 3.8.0 + mingw-gcc

On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > FWIW, I'm also suddenly experiencing segfaults in code that used to > work > a few days ago (I'm using svn). This may be unrelated to the problem > described below, but perhaps it's the same thing. > > In my case it seems that creating an ExecutionEngine has changed. I > used > to do > > Module* Mod

I believe the correct way is actually include the Interpreter’s header and the rest is handled automatically. Should be similar for MCJIT Zhang > On 11 May 2018, at 05:21, Aaron via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Ok. I figured out. Following methods needs to be called. That fixed the issue. > > llvm::InitializeNativeTarget(); >

Ok. I figured out. Following methods needs to be called. That fixed the issue. llvm::InitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); LLVMLinkInMCJIT(); Aaron On Thu, May 10, 2018 at 8:33 PM, Aaron <acraft at gmail.com> wrote: > Hello, > > When I try to create execution engine I do get "*Interpreter has not been > linked

Hi Larry, Thanks so much! This seems to do the trick. I would have spun my wheels for > a long time before discovering all of this, wow. No worries. :) I'll try to keep this in mind and make sure I address it in future Kaleidoscope tutorial chapters - these issues tripped me up the first time I encountered them too. Do I even want to know what additional chickens need to be sacrificed

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