similar to: Quality of LLVM headers

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, >> > > >>

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

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

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

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

Hello everyone, Are there any reasons the unittests in LLVM repo are split into independent executables, e.g. ADTTests, AnalysisTests, etc. Are there any performance or easy-to-use reasons for this? I plan to migrate to GTest from a project where we have all unittests in a single executable. - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

Hi, Recently I was hit by an assert in WinCOFFObjectWriter that had forbidden storing pointer to string table in header name field when the pointer had more that 6 decimal digits. This limit had been chosen to make implementation easier (sprintf adds null character at the end) and could be increased to 7 digits. My patch is attached. The implementation uses additional buffer on the stack to make

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Friday, May 22, 2015 8:45:11 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > > > > Any comments? Not in particular, but I think we're pretty close to applying a rewrite by Jonas Paulsson

----- Original Message ----- > From: "Paweł Bylica" <chfast at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Jonas Paulsson" <jonas.paulsson at ericsson.com> > Sent: Friday, May 22, 2015 9:19:14 AM > Subject: Re: [LLVMdev] Problems with instruction scheduling > >

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 "

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”.

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

Hi, I'm interested in any information about implementations of switch instruction and its runtime cost. If it's very target dependent, I'm mostly care about X86. Pointing some LLVM code is also good. - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/285f02e5/attachment.html>

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Paweł Bylica" <chfast at gmail.com> > Sent: Wednesday, July 1, 2015 6:42:41 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what to

Hello everyone, I need some advises about (re)using ExecutionEngine with MCJIT as a driver. I'm developing a service that receives a piece of high-level code, compiles it into LLVM IR function "main" and uses MCJIT to execute the function. It can happen that the same piece of code is sent to the service many times. I would like to cache the results (keep generated machine code

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:

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Paweł Bylica" <chfast at gmail.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, July 1, 2015 12:08:37 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what

On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009,