search for: llvminitialize

Hi, Using a JIT engine on LLVM-C currently fails on SVN because the LLVMInitialize???Info is never called. The attached patch fixes this. BTW, would it be possible to include a simple LLVM-C test case, like http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html, into the test suite, and build/test regularly to prevent regressions like this? Jose -----------...

Applied as r79307, thanks On Sat, Aug 15, 2009 at 8:57 AM, José Fonseca<jose.r.fonseca at gmail.com> wrote: > Hi, > > Using a JIT engine on LLVM-C currently fails on SVN because the > LLVMInitialize???Info is never called. > > The attached patch fixes this. > > BTW, would it be possible to include a simple LLVM-C test case, like > http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html, > into the test suite, and build/test regularly to prevent regressions...

...2009 at 10:06 PM, Daniel Dunbar<daniel at zuster.org> wrote: > Applied as r79307, thanks > > On Sat, Aug 15, 2009 at 8:57 AM, José Fonseca<jose.r.fonseca at gmail.com> wrote: >> Hi, >> >> Using a JIT engine on LLVM-C currently fails on SVN because the >> LLVMInitialize???Info is never called. >> >> The attached patch fixes this. >> >> BTW, would it be possible to include a simple LLVM-C test case, like >> http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html, >> into the test suite, and build/test regularly...

...ter main(), StaticPassRegistry can be considered immutable. In main(), the existing PassRegistry initializes itself from the StaticPassRegistry. This *should* solve all the problems, the only trick is finding every executable that uses the PassRegistry. it's times like this I wish we have an LLVMInitialize() function which every executable using LLVM is required to call early in main(). On Mon, Jun 2, 2014 at 9:14 AM, David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I ran into this a few weeks ago trying to tidy up ownership of > the PassRegistry and it made me sad. Chatting to Cha...

...in turn tries to deregister the pass) and what would happen is that > the global would be reconstructed, its pimpl would be reinitialized to > null and the deregistration function would stop there... subtle and > annoying) > > > > > it's times like this I wish we have an LLVMInitialize() function which > every > > executable using LLVM is required to call early in main(). > > > > > > On Mon, Jun 2, 2014 at 9:14 AM, David Blaikie <dblaikie at gmail.com> > wrote: > >> > >> Yeah, I ran into this a few weeks ago trying to tidy up...

Hola Aaron, Just having that code didn't work since the linker still stripped it out, so I have that function called from the code in the system that actually is being used by our app. Kinda grubby, but I include: #include "llvm/lib/Target/X86/X86TargetMachine.h" Which is in the LLVM lib, not the LLVM inc directory. This little maneuver made our Mac builds really unhappy, so

Thanks for your response Chuck. >From this and the other responses to my question, it looks like I'm including all the right object files, so it must be something with Visual Studio stripping "dead" code. So, given your response Chuck, I have a few questions. First, what exactly is the code that VStudio seems to be stripping? I might be able to figure out how to prevent it

+cc original authors of these changes. Is PassRegistry intended to be thread-safe? The header file explicitly says that PassRegistry is not thread-safe, but there are mutexes and locking used in the code. This is actually creating a problem, because of a subtle bug involving static initialization order and shutdown. In particular, the RegisterPass<> static template will get invoked