similar to: [LLVMdev] Announcing: LLVM 2.8 Release Candidate 2 Tagging Tonight

On Sep 15, 2010, at 12:46 AM, Albert Graef wrote: > Bill Wendling wrote: >> Release testing of Release Candidate 1 is finished. I'll be tagging >> Release Candidate 2 tonight. If there are any fixes you want in, please >> get them approved as soon as possible. > > Are there any tarballs for the release candidates available? Tanya used > to make these available

Bill Wendling wrote: > Release testing of Release Candidate 1 is finished. I'll be tagging > Release Candidate 2 tonight. If there are any fixes you want in, please > get them approved as soon as possible. Are there any tarballs for the release candidates available? Tanya used to make these available for previous releases, but I haven't been able to find any for testing 2.8.

On Wed, 15 Sep 2010 01:50:24 -0700 Bill Wendling <wendling at apple.com> wrote: > On Sep 15, 2010, at 12:46 AM, Albert Graef wrote: > > > Bill Wendling wrote: > >> Release testing of Release Candidate 1 is finished. I'll be tagging > >> Release Candidate 2 tonight. If there are any fixes you want in, > >> please get them approved as soon as

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

Hi all! The 3.1 release is scheduled for next Monday. Please check the ReleaseNotes.html file to make sure that it's up-to-date. Thanks! -bw

Hi, are there any attempts to use LLVM in graph-rewriting (term-rewriting) language implementations? How good is LLVM for this? E.g., is it natural to expect that the LLVM-based implementation of the language Concurrent Clean be any faster than its reference implementation? Best regards -- Valery A.Khamenya -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

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

Jon Harrop wrote: > 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? FWIW, Pure uses TCO as well and that works fine with LLVM 2.8, both with the JIT and with statically compiled code, at least on x86_64. -- Dr. Albert Gr"af Dept. of Music-Informatics,

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

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:

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

Ó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

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

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

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.

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