similar to: [LLVMdev] Building With GCC 4.0.1

Hi John, llvm-gcc4 by default emits object files, just as gcc does. This is by design. If you want to get bytecode output you need to use the --emit- llvm-bc option. A complete list of the options that llvm-gcc4 supports can be obtained with "llvm-gcc -v --help" (lots of output). Here are the descriptions of the --emit-llvm options: -emit-llvm Emit LLVM code to the

Andreas, This has been seen before and I believe fixed in the CVS version. See http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=578 for details. The problem was fixed June 6 by Nate. The patches are included in the bug report. You can either apply the patches to your 1.5 sources, use CVS, or downgrade your compiler to 3.4 Reid. Andreas Fredriksson wrote: > Hey guys, > I just moved to the

Hmm, today I just tried compiling the llvm-gcc 4.0 frontend again on linux (Fedora Core 3 I believe) and I seem to be suddenly having the problem that Yossi Kreinin mentioned. The frontend seems to be using normal gcc to compile as I no longer get a bytecode file after compilation. When I pass the --version argument it claims to be the LLVM 4.0.1 frontend. Any ideas what might cause this? It was

Hi Kenneth, On Wed, 2006-11-08 at 11:58 +0100, Kenneth Hoste wrote: > Hello LLVM-people, > > I realize most of you have other things on their head now, with the > 1.9 release coming up, but I'd like to ask some questions regarding > the llvm-gcc frontend. Okay. > The current llvm-gcc4 frontend is based on GCC 4.0.1, as far as I can > tell from the docs. I also

The default prefix is /usr/local but I would recommend that when you configure LLVm you do so with: configure --prefix=/me/llvm/install/dir ... so that installation occurs in a place you have write access. If you feel strongly about restoring the install-bytecode target, feel free to file a bug. Reid. On Thu, 2004-11-11 at 09:12, Jeff Cohen wrote: > Wow... it is nearly twice as fast. But

On 6/3/06, Reid Spencer <reid at x10sys.com> wrote: > I don't think anyone has successfully built llvm-gcc4 on Linux yet. I've > tried and failed. I have :-) There was some patches, but I believe that they were all merged in the latest snapshot. Rafael

Hey guys, I just moved to the 1.5 release yesterday. I compiled the Debug version cleanly from sources (I'm not using the gcc frontend) using GCC 4.0.1 (on Fedora Core x86), and I noticed that llc hung in an STL iterator loop given trivial bytecode input (essentially a single function to add a couple of integers). The bytecode compiled fine from llvm assembly via llvm-as. The hang was in one

This kind of thing is one of the many reasons we broke llvm-test out to a separate project. It has multiple purposes. Its a correctness test on LLVM, its what we base our compiler benchmarks on, and its also where a lot of the research gets done. You've been bitten by the latt(n)er. :) At some point I'd like to see us make some distinctions so that there is a correctness test suite whose

I forgot that lli was "special". It uses the "JIT" keywoard which means "figure out the right libraries to use for a JIT compiler and runtime". So, just add this, to tools/lli/Makefile: USEDLIBS := LLVMBCWriter That worked for me. Reid. On Thu, 2005-02-24 at 16:58, Patrick Meredith wrote: > Where do I add that line? Just putting it in the vanilla Makefile in

I don't think anyone has successfully built llvm-gcc4 on Linux yet. I've tried and failed. The instructions in CFEBuildInstrs.html are for llvm-gcc3 and probably won't work as-is. Reid. On Sat, 2006-06-03 at 19:39 +0300, Yossi Kreinin wrote: > Hi! > > Apparently there are no precompiled binaries for llvm-gcc 4.0 for Linux. > > I've tried downloading the sources

The entire makefile system was rewritten a couple of weeks ago. This is a good thing, your compiles now go twice as fast. Resistance is futile, just adapt :) The install target installed the bytecode libs into CFEINSTALL as before and also installs the native libraries to your prefix/lib directory. This is intentional. Reid On Wed, 2004-11-10 at 23:32, Jeff Cohen wrote: > But there already

On Thu, 11 Nov 2004, Reid Spencer wrote: > This kind of thing is one of the many reasons we broke llvm-test out to > a separate project. It has multiple purposes. Its a correctness test on > LLVM, its what we base our compiler benchmarks on, and its also where a > lot of the research gets done. You've been bitten by the latt(n)er. :) > > At some point I'd like to see us

Where do I add that line? Just putting it in the vanilla Makefile in tools/lli doesn't work. ----- Original Message ----- From: "Reid Spencer" <reid at x10sys.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, February 24, 2005 6:50 PM Subject: Re: [LLVMdev]Linker error building (modified) lli >

No, I don't feel strongly about it... it's just annoying to have things change on me that break habits :) On the other hand, I do feel strongly about the tests in llvm-test that are now failing on me because they explicitly include alloca.h, a file that does not exist on FreeBSD. I can supply a patch to take out the include, of course, but the problem then becomes that the tests will

Wow... it is nearly twice as fast. But it tried to install stuff in /usr/local (and as I wasn't root...) and it didn't do that before. As I don't care about profiling or tracing, I didn't bother to su and do it again. On Wed, 10 Nov 2004 23:45:35 -0800 Reid Spencer <reid at x10sys.com> wrote: > The entire makefile system was rewritten a couple of weeks ago. This is

Hi Patrick, You need to modify your makefile for building your version of lli so that it includes the LLVMBCWriter.o library. You can do this with a line like: LLVM_LIBS=LLVMBCWriter if you're using the LLVM Makefile system. Otherwise you just need to make sure that {Debug,Release}/lib/LLVMBCWriter.o gets added to the link line. Reid. On Thu, 2005-02-24 at 16:37, Patrick Meredith wrote:

But there already was an "install", and it did far more than install the bytecode files. That changed too? On Wed, 10 Nov 2004 23:28:27 -0800 Reid Spencer <reid at x10sys.com> wrote: > Yeah, its just "install" now. > > I'll fix the documentation. > > Reid. > > On Wed, 2004-11-10 at 23:19, Jeff Cohen wrote: > > My rebuild from scratch

On Tue, 2003-11-18 at 15:11, Vikram Adve wrote: > This is a hot topic in the compiler research community, but the focus > there is on > (a) choosing the right optimization sequences internally and > transparently, rather than through combinations of options, > (b) performance prediction techniques so you don't actually have to run > gazillion different choices, and perhaps

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it

Michael, I've implemented a LOADABLE_MODULE feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library