similar to: [LLVMdev] __STDC_LIMIT_MACROS

Hello All, I build source code of Ocelot[http://code.google.com/p/gpuocelot/]. It using LLVM dependency of Ocelot. llvm-config get cppflags represent as below in order to build with Ocelot. ./llvm-config --cppflags -I/home/chatsiri/workspacecpp/llvm/include -I/home/chatsiri/workspacecpp/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

It's not much. (gdb) bt #0 0x00007ffff7f6506b in ?? () #1 0x000000000045d01a in main () at main.cc:165 Line 165 is the call to the function that was compiled by the JIT'er. Meaning that JIT'ing the function went well, but the code or the pointer are somehow corrupt. There is no particular reason why I am working with the legacy interface. Would you recommend to use the MCJIT

After I actually get everything compiling, install the library, and load it from my Java program, I get the following: > Exception in thread "main" java.lang.UnsatisfiedLinkError: > /usr/lib/libjllvm.so: /usr/lib/libjllvm.so: undefined symbol: > _ZTVN10__cxxabiv120__si_class_type_infoE If I have to guess, this means that the CMake stuff given is linking to the C++ libraries

Eli Gottlieb <eligottlieb at gmail.com> writes: > I compiled and installed it to the prefix /usr, but that's not the > issue. Once I actually compile and install LLVM with CMake by hand, I > get the share/llvm/cmake stuff installed correctly (can those files be > included in "normal" builds, or will LLVM switch to CMake as its > primary build system?). Now

Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Mon, Jun 20, 2016 at 05:05:18PM +0000, Paweł Bylica via llvm-dev wrote: >> On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: >> >> > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: >> > > Hi LLVM, >> > > >>

I compiled and installed it to the prefix /usr, but that's not the issue. Once I actually compile and install LLVM with CMake by hand, I get the share/llvm/cmake stuff installed correctly (can those files be included in "normal" builds, or will LLVM switch to CMake as its primary build system?). Now I'm running into the problem of cflags or includes or something not being

On Thu, Sep 8, 2011 at 11:52 PM, geovanisouza92 at gmail.com < geovanisouza92 at gmail.com> wrote: > I set the '__STDC_LIMIT_MACROS' and '__STDC_CONSTANT_MACROS' defines, and > save the "DataTypes.h.in" as "DataTypes.h", to compiler can locate them. > Don't do this, it's wrong. The "DataTypes.h" should be created from "

Hi everyone! I'm trying compile an compiler project that uses LLVM 2.9, and I'm having difficult with the error "Don't have a definition for uint64_t on this platform". I set the '__STDC_LIMIT_MACROS' and '__STDC_CONSTANT_MACROS' defines, and save the "DataTypes.h.in" as "DataTypes.h", to compiler can locate them. I'm using

From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm compiles fine; ours is compiled to a Debugging version. llvm-gcc, though, is angry. I get the following error (with path prefixes shortened for convenience) when compiling llvm-gcc: > In file included from

On 08/13/2009 07:35 PM, Matt Elder wrote: > From an x86-64 machine, I'm trying to compile llvm and llvm-gcc. I'm > using the LLVM 2.5 release, and the associated llvm-gcc tarball. llvm > compiles fine; ours is compiled to a Debugging version. llvm-gcc, > though, is angry. I get the following error (with path prefixes > shortened for convenience) when compiling llvm-gcc:

Do you have a stack trace of the segfault? We have two different code emitters for X86 in LLVM. The one used by the normal compiler and MCJIT and the other used by the legacy JIT. All of the test cases for AVX support go through the first one so it gets the most attention. We try to keep the legacy JIT in sync with it, but have a history of failing at that. The stack trace of the segfault may

Hi Ashok, I created a new Ubuntu 12.04 virtual machine and followed directions except that I know use your cmake command instead of configure, and I got the error below. Any help is very much appreciated. $ /home/ubuntu/bin/bin/clang++ -I /home/ubuntu/bin/include/ tutorial1.cpp In file included from tutorial1.cpp:5: In file included from /home/ubuntu/bin/include/llvm/Support/raw_ostream.h:17:

hey guys. Now I am following the "Writing an LLVM Pass", but can't work it out. See what I have done. After completing the exact Makefile and source code under lib/Transforms/Hello, I typed the command "make" instead of "gmake" , then it generated silently "Hello.o" in Debug. But, next, when I tried to generate "hello.bc" by the command

Hello all, I'm trying to include and use the Module.h class into my project I get these 5 errors when I attempt to compile a cpp file that has #include <llvm/Module.h> (through eclipse) Description Resource Path Location Type #error "Must #define __STDC_CONSTANT_MACROS before " "#including System/DataTypes.h" template line 49, external

I get compile errors for just including the "clang/Basic/Diagnostic.h" header file. Is that expected? Should I include anything else? Here are the errors: $ g++ main.cpp -I llvm/tools/clang/include -I llvm/include In file included from llvm/include/llvm/Support/PointerLikeTypeTraits.h:18, from llvm/tools/clang/include/clang/Basic/SourceLocation.h:17,

On Sun, Jun 19, 2016, 17:57 Joerg Sonnenberger <joerg at bec.de> wrote: > On Sun, Jun 19, 2016 at 03:24:22PM +0000, Paweł Bylica via llvm-dev wrote: > > Hi LLVM, > > > > I want to complain a bit about the quality of the code included in the > > public LLVM headers. For projects that depend on LLVM is really hard to > > just include LLVM headers not to

Hi LLVM, I want to complain a bit about the quality of the code included in the public LLVM headers. For projects that depend on LLVM is really hard to just include LLVM headers not to trigger tons of warnings. Moreover, the is this issue that you have to define __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS everywhere just to include single DataTypes.h. Strangely, it seems to be required only

--- include/llvm-c/Core.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/llvm-c/Core.h b/include/llvm-c/Core.h index 3ffaddd..becba7f 100644 --- a/include/llvm-c/Core.h +++ b/include/llvm-c/Core.h @@ -33,6 +33,10 @@ #ifndef LLVM_C_CORE_H #define LLVM_C_CORE_H +#ifndef __STDC_LIMIT_MACROS +#define __STDC_LIMIT_MACROS +#endif + #include

On 15 November 2013 20:05, Frank Winter <fwinter at jlab.org> wrote: > Good catch! That was the problem in my case too. I totally > overlooked the alignment requirement for AVX. I wonder if the validation mechanism shouldn't have caught it earlier... Do you guys run validate on the modules before JIT-ing? --renato -------------- next part -------------- An HTML attachment was

On 1 July 2015 at 21:22, Frank Winter <fwinter at jlab.org> wrote: > there were two follow-up emails. I only got one... weird... > The issue is solved. The SLP vectorizer has > a magic number built into the code which determines the max. vector length > to search for. That was set to 128 bits. Increasing it to 256 bits solved > the issue. That looks like a simple fix. Is