similar to: [LLVMdev] LLVM-C bindings tutorial?

Hello, i am trying to build llvm 3.2 and early into the make proccess i am getting this error: llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td Could not open input file '/src/llvm-3.2.src/include/llvm/Intrinsics.td': No such file or directory Makefile:23: recipe for target `/src/llvm-3.2.src/build/lib/VMCore/Release+Asserts/Intrinsics.gen.tmp' failed make[1]: ***

This looks like you're trying to have your build directory be inside the source directory. Don't do that. -Jim On Dec 21, 2012, at 12:33 PM, Flexicat01 <nekroze.lives at gmail.com> wrote: > Hello, i am trying to build llvm 3.2 and early into the make proccess i am > getting this error: > > llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td > Could not open

Of course, my apologies, its late. Fixed now it seems mate thanks. -- View this message in context: http://llvm.1065342.n5.nabble.com/Build-failed-Intrinsics-td-no-such-file-it-is-there-tp52792p52794.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

I am looking at starting a project to make a toy language that is targeted purely at 64bit windows. I have never used llvm or anything like it i am just trying to learn new things. However there are several problems, as far as i have seen, with compiling llvm in 64bit on windows. So i was wondering if i compile a 32bit version of llvm and use that can my resulting compiler output 64bit binaries?

I did try the cygwin mingw-x86_64 but i couldn't get llvm to compile, but i did try and compile clang and compiler_rt as well, may have to try again soon. On windows i'm not interesting in i686 or any 32 bit compiling just 64 bit alone but i don't need a jit anyways for my language. If i use the cygwin environment to build llvm do i have to use cmake or can i use the standard

Hi Andrew, Am 04.06.2013 02:13, schrieb Kaylor, Andrew: > Hi Dmitri, > > You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been

On Sep 10, 2012, at 3:34 PM, Bob Wilson wrote: > Didn't Benjamin already fix this in svn 163502? Looks that way.. > On Sep 10, 2012, at 10:08 AM, Chad Rosier <mcrosier at apple.com> wrote: > >> >> On Sep 7, 2012, at 3:40 PM, Nuno Lopes wrote: >> >>> The linking issue is a recent breakage. >>> I traced it back to r163175. Basically

The linking issue is a recent breakage. I traced it back to r163175. Basically LLVMConstInlineAsm() got an additional parameter, but the C headers and the OCaml bindings were not updated accordingly. About the miscompilations, can you provide further details? Nuno ----- Original Message ----- > I've recently upgraded my project-local copy of LLVM from 3.1svn to the > latest

I've recently upgraded my project-local copy of LLVM from 3.1svn to the latest 3.2svn, and all hell broke loose in my attempts to build OCaml projects. Trying to narrow it down, I tried testing examples/OCaml-Kaleidoscope and eventually test/Bindings, only to discover that literally nothing in the repository which uses the OCaml bindings seems to build in the current trunk: -

Didn't Benjamin already fix this in svn 163502? On Sep 10, 2012, at 10:08 AM, Chad Rosier <mcrosier at apple.com> wrote: > > On Sep 7, 2012, at 3:40 PM, Nuno Lopes wrote: > >> The linking issue is a recent breakage. >> I traced it back to r163175. Basically LLVMConstInlineAsm() got an additional parameter, but the C headers and the OCaml bindings were not updated

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also

On Sep 7, 2012, at 3:40 PM, Nuno Lopes wrote: > The linking issue is a recent breakage. > I traced it back to r163175. Basically LLVMConstInlineAsm() got an additional parameter, but the C headers and the OCaml bindings were not updated accordingly. r163175 was my change. I'm not familiar with the OCaml project. If I'm responsible for updating said C headers/OCaml bindings, would

(cc'ing llvm-dev) Hello Gregory, i just recompiled llvm from scratch, and was able to build the ocaml kaleidoscope bindings. Did you know the llvm's build system already can compile the kaleidoscope tutorials for you? You can run this to build them: make BUILD_EXAMPLES=1 Or just cd into the examples directory in your build directory, and run "make" there. Anyway, I think the

2012/12/21 Flexicat01 <nekroze.lives at gmail.com>: > I am looking at starting a project to make a toy language that is targeted > purely at 64bit windows. I have never used llvm or anything like it i am > just trying to learn new things. > > However there are several problems, as far as i have seen, with compiling > llvm in 64bit on windows. So i was wondering if i compile

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

On Mon, Jul 26, 2010 at 10:15 AM, Jason Johnson <jason.johnson.081 at gmail.com> wrote: > Hello list, > > Since reading the kaleidoscope tutorial I have decided to play around with creating a language I've had in the back of my mind for some time.  I would prefer not to write the front end in c or c++ though if it can be avoided.  I read online that the ocaml bindings are

On Fri, Mar 28, 2008 at 12:00 AM, Mahadevan R <mdevan.foobar at gmail.com> wrote: > 1) > Are the C bindings complete? That is, is there some part of the C++ API > that is not exposed by the C API? Nope, there's still a lot that's not done. Patches are always welcome :) We've got enough in subversion to implement the Kaleidoscope tutorial though. > 2) > Do

Hi Dmitri, You're right. The lli code should be cleaned up. As David said, there was a time when the call to invalidate the instruction cache was necessary. It isn't necessary anymore. -Andy -----Original Message----- From: Dmitri Rubinstein [mailto:dmitri.rubinstein at googlemail.com] Sent: Tuesday, June 04, 2013 7:20 AM To: David Tweed Cc: Kaylor, Andrew; LLVM Dev Subject: Re:

The link to the next chapter in the navigation list at the top of this page of the OCaml Kaleidoscope tutorial goes to the C++ version: http://llvm.org/docs/tutorial/OCamlLangImpl3.html. The link to chapter 8 in the first chapter is broken: http://llvm.org/docs/tutorial/OCamlLangImpl1.html#intro. It links to the unvavailable page http://llvm.org/docs/tutorial/OCamlLangImpl8.html. I think it

I've just committed the first two chapters of my ocaml llvm bindings tutorial by porting the Kaleidoscope tutorial to ocaml. These chapters are the lexer and parser. If anyone is interest in trying it out, I'd love any feedback. If you've got the svn trunk checked out, you'll find the docs here: docs/tutorial/OCamlLangImpl1.html docs/tutorial/OCamlLangImpl2.html If not, you can