similar to: [LLVMdev] LLVM 3.0rc4 testing begins!

PS: A more convincing (IMO) argument against dragonegg is that it doesn't work on windows. That's because the gcc plugin architecture doesn't work on windows. Takumi has been thinking about this and has been enable to get dragonegg to work on windows anyway using some clever tricks.

Hi Duncan, On 10/17/2011 04:44 PM, Duncan Sands wrote: > PS: A more convincing (IMO) argument against dragonegg is that it doesn't > work on windows. That's because the gcc plugin architecture doesn't work > on windows. Takumi has been thinking about this and has been enable to > get dragonegg to work on windows anyway using some clever tricks. Interesting, thanks for

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 10/17/2011 10:09 AM, Duncan Sands wrote: > llvm-gcc is dead, deprecated in favour of clang and dragonegg. It won't be part > of the upcoming 3.0 release. This is why no-one is interested in working on it. The tentative release notes still say otherwise: "LLVM 3.0 will be the last release of llvm-gcc." (http://llvm.org/docs/ReleaseNotes.html) I understand that llvm-gcc

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,

On 10/17/2011 02:00 PM, Duncan Sands wrote: > this was a result of someone replacing 2.9 with 3.0 everywhere in that doc. > If you check the 2.9 release notes you will see that this was announced in > 2.9 release. Ah, I should have thought of that. :) > The 3.0 version does not require a patched gcc-4.5. It also works with > gcc-4.6. It does have its rough spots, but they were

> > .... but some Pure users and many of my students do. Pure relies on > LLVM-capable compilers for its C/C++/Fortran > inlining capabilities, so being able to just point Windows users to a > binary llvm-gcc package to make that work is very convenient. Nice to be called "Pure" :-) especially with capital letter. MinGW binaries for llvm-gcc don't have Fortran

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

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

On Aug 25, 2009, at 12:24 PM, Albert Graef wrote: > Trunk (r80020): > raw_fd_ostream(const char *Filename, std::string &ErrorInfo, > unsigned Flags = 0); > > It would be helpful to emulate the LLVM 2.5 variant of the constructor > on both 2.6 and trunk, so that frontend developers don't have to code > against three different versions of the

Eli Friedman wrote: > This isn't first-hand, but from what I remember hearing on IRC, > putting llvm into shared libraries caused a ridiculous explosion in > dynamic linking (and therefore startup) times. So there is no option > to make shared libraries, at least at the moment. Well, by tweaking configure and make options, I've managed to build LLVM 2.2 shared libraries on

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:

Dear All, The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X. The following patch seems to fix it (it adds a missing include file to get WeakVH defined). Has anyone else seen this breakage, or is it possible that I've got the wrong branch checked out? -- John T. Index: lib/Transforms/Scalar/DeadStoreElimination.cpp

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

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

On Monday 09 June 2008, Albert Graef wrote: > Unfortunately, that approach doesn't work on x86-64 with LLVM 2.2, > since some parts of the LLVM JIT apparently contain non-relocatable > code; I hope that this will be fixed in the forthcoming LLVM 2.3. Unfortunately it's not fixed in 2.3 :( I made a patch ([1]) for 2.2 and gave it to one of the developer, I guess he forgot about

Currently, there's a regression in llvm-config in both the 3.1 Release branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The attached patch fixes that. It would be great if this could be reviewed and still integrated into 3.1. Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL:

Albert, > The problem with using -fPIC on x86 is not only the speed of the > generated code, I also get JIT-related segfaults in the Pure interpreter > (on Linux). See, e.g.: Please fill a PR in the LLVM bugzilla, so this issue won't get lost. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Arnamoy Bhattacharyya wrote: > Hi all; > > Problem: Running a bitcode file produced by llvm-gcc (gcc 4.6.3 + > dragonegg 3.1 + llvm 3.1) with lli (Ubuntu 12.04) > > /llvm-gcc:/ > > llvm-gcc -c hello.c -emit-llvm -o hello.bc > lli hello.bc > > output: > lli: hello.bc:1:1: error: expected top-level entity > ELF@4( > > /clang:/ > > clang -c hello.c

Jeffrey Yasskin wrote: > See Owen's email about docs for the 2.6 release, but it's really not > that hard to keep up with trunk. I recently merged trunk LLVM into > Unladen Swallow, and the changes I needed to make are at > http://code.google.com/p/unladen-swallow/source/detail?r=724. Thanks Jeffrey, that was really very helpful! I have Pure working with both the LLVM 2.6