similar to: [LLVMdev] LLVM 2.6 Branch Fails to Compile

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

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

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,

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

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:

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

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

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

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

Ó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

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.

On Sun, Nov 29, 2009 at 2:19 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > 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

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

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

Hi All, Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Let me know if you have any additions, improvements, or see any oversights. If you have commit access, please just directly change the document. The release is planned to go out in about 24 hours from now! Thanks! -Chris