similar to: [LLVMdev] InitializeNativeTarget

Kenneth Uildriks wrote: > It seems that a client application needs to call > InitializeNativeTarget or LLVMInitializeNativeTarget before doing any > JITting. Unfortunately, LLVMInitializeNativeTarget is defined static > inline and does not appear in the .a files; thus a client not written > in C or C++ trying to JIT cannot link to the library and call >

On Wed, Oct 7, 2009 at 11:36 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > Kenneth Uildriks wrote: > > Yes, so you'll need to add a little C++ module to your wrapper that does > the necessary initializations and is callable from your target language. That's odd, we don't need to do that for ocaml. Have you tried having a function like this defined in your

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

Hello All, I'm building an F# binding for LLVM and it seems to be working for the parts of Core and BitWriter that I've tested but I've hit problems with Target/ExecutionEngine. The following test code works with the initializeNativeTarget line commented out like so: <https://github.com/keithshep/llvm-fs/blob/b7050b841108dc703e58563a4cff8845603c950d/test/simpletest2.fs> ...

Hello, I'm using the llvm-c bindings for C, but I'm getting some problems, the LLVMCreateExecutionEngine is returning 1 but the error message is an empty string (it's !=NULL). The steps I'm doing is to create the module, then I call LLVMVerifyModule to verify and it works fine, later I call LLVMCreateModuleProviderForExistingModule and it returns !=NULL MP, so it's ok, but

I've been struggling to get LLVM to work from .NET using the llvm-fs bindings for the past few weeks. I finally found an installation procedure that works and documented it here: http://fsharpnews.blogspot.com/2012/03/using-llvm-from-f-under-windows.html The good news is that I have that program compiling the Fibonacci function and executing it from F# all via LLVM. However, I still have a

Hi, when building llvm as a shared library LLVMInitializeNativeTarget and co. (located in llvm/Support/TargetSelect) will not get exported as symbol into the shared library, because they are static inline. Since they are functions defined in the C API no one else inside LLVM calls them, which results in them not being exported. This is, of course, no problem for C programs using the C API,

Hello, I have a question concerning llvm-c. I have set up a function that needs to invoke an external method, in a other library. It has the following signature: void* NSFullUserName(void); The void* can be replaced with a i8*, that far I was able to get, but when my call is invoked, the engine gives me the following message: LLVM ERROR: Tried to execute an unknown external function: i8* ()*

Owen Anderson wrote: > On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: >> >> You mean like this subject ? >> >> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html > > Notice the sender line on that email... ;-) Yes, you indeed announced that change, but as John rightfully remarked, the announcement gave little detail. For LLVM users like me,

Trying to get the Pure compiler to work with LLVM 3.1, I've run into a problem. The release notes say: "Target specific options have been moved from global variables to members on the new TargetOptions class, which is local to each TargetMachine." Unfortunately, they don't say anything about how to fix existing source to work around this. In my application I create a JIT

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

On Wed, Jul 15, 2009 at 2:24 PM, Albert Graef<Dr.Graef at t-online.de> wrote: > Owen Anderson wrote: >> On Jul 15, 2009, at 10:56 AM, Jean-Daniel Dupas wrote: >>> >>> You mean like this subject ? >>> >>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-June/023505.html >> >> Notice the sender line on that email... ;-) > > Yes, 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,

Óscar Fuentes wrote: > Some points you mention on your web page are solved. Which ones? (Just curious.) > Others are not applicable to LLVM. That might be the case now, but the lack of even basic functionality in some areas (in particular, no advanced feature checks, no make dist/distcheck, no make uninstall, lack of useful trace options when something goes wrong during a build, arcane

Albert Graef <Dr.Graef at t-online.de> writes: [snip] > Here are some points worth considering: > http://www.remlab.net/op/cmake.shtml (Some of these may already be > addressed in newer cmake versions, I haven't checked recently.) Albert, Some points you mention on your web page are solved. Others are not applicable to LLVM. Others can be fixed within CMake itself (with some

I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows so I think TCO isn't working. Have there been any obvious changes that would cause this? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com

Hello, in order to get ready for the upcoming LLVM 3.1 release, I checked out the 3.1 Release branch. However, unlike with LLVM 3.0, `llvm-config --libfiles` now also reports files that belong to targets that I did not build (and that are thus not available). Is this expected? Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL: