similar to: [LLVMdev] merge request for 2.6

Tomas Lindquist Olsen wrote: > For 2.6 to really be a useful, we need this bug fixed: > > http://llvm.org/bugs/show_bug.cgi?id=4963 > > Would it be possible to get this merged into 2.6? While we're at it, what about: http://llvm.org/bugs/show_bug.cgi?id=3239 This is a real nuisance, as people regularly build LLVM in a way (--enable-pic, which even is the default now) which

Hello, Albert > While we're at it, what about: > http://llvm.org/bugs/show_bug.cgi?id=3239 > > This is a real nuisance, as people regularly build LLVM in a way > (--enable-pic, which even is the default now) which makes the JIT create > wrong code on x86-32. I've seen this on Ubuntu and Fedora Core 10 > (thankfully Michel Salim has fixed the FC LLVM packages now).

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

John Criswell wrote: > 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? I fails to compile on Linux as well. Has been that way for a few days. Albert --

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:

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

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.

Jon Harrop wrote: > I've come up with the following minimal repro that segfaults on my machine: Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so

Dear All, I am considering a possibility of using LLVM JIT for an algebraic modelling language. I have already done some prototyping following the Kaleidoscope tutorial and currently thinking of how to connect the jitted code to a runtime library (for this language) which I would like to code in C++. If it was *NIX I would use g++ possibly with '-rdynamic' option as suggested in the

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

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:

Victor Zverovich wrote: > I am considering a possibility of using LLVM JIT for an algebraic > modelling language. I have already done some prototyping following the > Kaleidoscope tutorial and currently thinking of how to connect the > jitted code to a runtime library (for this language) which I would like > to code in C++. If it was *NIX I would use g++ possibly with

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