similar to: [LLVMdev] rdynamic on Mac

Renato Golin wrote: > I've read some posts on the web indicating problems with the -rdynamic > option on Mac's GCC, but I'm not sure. What's the Mac-style for that? -rdynamic doesn't exist on OSX, nor should it be needed. Just make sure that you do *not* strip the executable (i.e., avoid strip, install -s, etc.), IIRC that's needed to make dlopening the executable

John McCall wrote: > On Jul 2, 2009, at 1:05 AM, Carter Cheng wrote: >> I am having some difficulties getting the LLVM JIT to resolve extern >> "C" functions which I have defined in source file and invoking them >> via EE::runFunction() after generating a Function prototype for it. >> Is this possible or do I need to generate a .so for my functions are

Anton Korobeynikov wrote: > > Hello, > >> ready> ERROR: Program used external function 'putchard' which could not >> be >> resolved! >> Any idea of what could be wrong? > Please make sure you're using C linkage for such functions, due to > mangling the name of > function being emitted is not "putchard". Something like this: >

Hello, > ready> ERROR: Program used external function 'putchard' which could not be > resolved! > Any idea of what could be wrong? Please make sure you're using C linkage for such functions, due to mangling the name of function being emitted is not "putchard". Something like this: extern "C" void putchard(char c) { ... } Or, just provide a mapping

2009/7/4 Albert Graef <Dr.Graef at t-online.de>: > This is all I ever needed to interface to C functions using LLVM. It's > really easy. Of course you still need a prototype of the external > function (function definition without body) in your IR, but that's it. Hi Albert, I'm having a similar problem and I found I can't declare the function and use it, most likely

Dear All, I am considering a possibility of using LLVM JIT for an algebraic modelling language. I have already done some prototyping following the Kaleidoscope tutorial and currently thinking of how to connect the jitted code to a runtime library (for this language) which I would like to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic' option as suggested in the

mriou wrote: > Using the sin(x) and cos(x) functions work though, only the ones included in > the main file don't. So I'm a bit puzzled... Did you link your executable with -rdynamic? -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW:

Victor Zverovich wrote: > I am considering a possibility of using LLVM JIT for an algebraic > modelling language. I have already done some prototyping following the > Kaleidoscope tutorial and currently thinking of how to connect the > jitted code to a runtime library (for this language) which I would like > to code in C++. If it was *NIX I would use g++ possibly with

Hi I hope this is a proper place to put my question. I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. Basically it works just fine but when I try to run extern'ed putchard function it aborts. Please, tell me what am I doing wrong? Here is more information: My PC runs FreeBSD. I've copied the toy source code exactly and didn't change it.

Thank you very much for you help, Renato! I read through paper you referred and also this document - http://llvm.org/docs/tutorial/JITTutorial1.html Following these instructions to create successful function I run into some problems: 1) llvm::getGlobalContext() does not exists anymore? "llvm/LLVMContext.h" too? 2) creating instance of IRBuilder don't require template (from tutorial

2009/11/5 Oleg Knut <oleg77 at gmail.com>: > Hello, > I have a simple question. How to create "dummy" function which will > have no functionality behind (return nothing and do nothing)? > Currently I'm trying to do this: > > llvm::Constant* c = Module.getOrInsertFunction("dummy", > FunctionThatNeedsToBeReplaced.getFunctionType()); >

Albert and Anton, thanks for all the answers. I tried to load a DLL with DynamicLibrary::LoadLibraryPermanently and it works perfectly, so there is no need to use ExecutionEngine::addGlobalMapping. However Function objects still need to be constructed since they are required when creating a call, right? Victor 2009/6/15 Albert Graef <Dr.Graef at t-online.de> > Victor Zverovich wrote:

On Jul 2, 2009, at 1:05 AM, Carter Cheng wrote: > I am having some difficulties getting the LLVM JIT to resolve extern > "C" functions which I have defined in source file and invoking them > via EE::runFunction() after generating a Function prototype for it. > Is this possible or do I need to generate a .so for my functions are > link against it? If the JIT needs

Hi, I am having some difficulties getting the LLVM JIT to resolve extern "C" functions which I have defined in source file and invoking them via EE::runFunction() after generating a Function prototype for it. Is this possible or do I need to generate a .so for my functions are link against it? Thanks in advanced, Carter. Sorry for the double post but apparently I mistakenly tagged

What exactly is M in that code you posted? Oleg Knut wrote: > > Thank you very much for you help, Renato! > > I read through paper you referred and also this document - > http://llvm.org/docs/tutorial/JITTutorial1.html > > Following these instructions to create successful function I run into > some problems: > 1) llvm::getGlobalContext() does not exists anymore?

I think you might have to provide an empty list if your function doesn't take parameters. Maybe using an irbuilder would help? -bw On Aug 22, 2009, at 2:13 PM, Renato Golin <rengolin at systemcall.org> wrote: > 2009/7/4 Albert Graef <Dr.Graef at t-online.de>: >> This is all I ever needed to interface to C functions using LLVM. >> It's >> really

Albert Graef <Dr.Graef at t-online.de> writes: > On 06/21/2012 04:22 PM, Óscar Fuentes wrote: >> About the "many features" that cmake lacks, can you provide a list, >> please? > > Generally it works fairly well, but here are some differences to the > autoconf-based build I noticed: > > - No 'make uninstall'. That is a real deal breaker if you

Duncan Sands wrote: > Do ordinary users need to have cmake if they want to build llvm? > If so, that's bad because they'll have to install it (unlike the > current setup, where only very standard tools are needed). That's not the only problem with cmake. The autotools may be a big and ugly beast, but that's because they're trying to solve a big and ugly problem for

Ok, I attached it to the bug. For reference, here's what I'm using on unix as a workaround as long as this is not fixed: llvm-config --libfiles | xargs -n 1 -I {} sh -c 'test -f {} && echo {}' On Tue, May 15, 2012 at 1:07 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > On 05/13/2012 02:46 AM, Keno Fischer wrote: > > Currently, there's a regression

I am somewhat surprised people are actually using TCO. I had to fixed a number of subtle bugs to get it working and even now I am not too happy with it. My focus was on finding non-ABI changing automatic tail call cases (aka gcc's sibcall). It's now done so I'll leave -tailcallopt alone for now. I'll run -tailcallopt as x86 llcbeta to see if JIT is indeed broken. Evan On Feb 5,