Hi All, There's a new snapshot of llvmgcc4 available here: http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gz This release includes the various portability fixes contributed on llvmdev, includes fixes to build with mainline CVS (and, thus, *requires* mainline CVS), and includes various other bug fixes. If you're interested, please try it out. Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/
Hi, i tried compiling llvmgcc4 on x86_64-linux. The two changes i needed to apply to llvm and llvmgcc4 are attached. Those two patches tell llvmgcc4 to use the x86 code-generator for x86_64 and give x86_64-* targets a score of 10 for the x86 backend when trying to find appropriate backends. Now i'm getting stuck during the compile when an assertion is triggered: make[3]: Leaving directory `/home/mcm/projects/llvm/build-gcc4/gcc' /home/mcm/projects/llvm/build-gcc4/gcc/xgcc -B/home/mcm/projects/llvm/build-gcc4/gcc/ -B/home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/bin/ -B/home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/lib/ -isystem /home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/include -isystem /home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../2006-05-08-llvm-gcc-4/gcc -I../../2006-05-08-llvm-gcc-4/gcc/. -I../../2006-05-08-llvm-gcc-4/gcc/../include -I../../2006-05-08-llvm-gcc-4/gcc/../libcpp/include -I/home/mcm/projects/llvm/build-release/../llvm-cvs/include -I/home/mcm/projects/llvm/build-release/include -DL_mulsc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_mulsc3.o cc1: /home/mcm/projects/llvm/build-release/../llvm-cvs/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:2826: llvm::SDOperand <unnamed>::SelectionDAGLegalize::PromoteOp(llvm::SDOperand): Assertion `getTypeAction(VT) == Promote && "Caller should expand or legalize operands that are not promotable!"' failed. ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c:1714: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://developer.apple.com/bugreporter> for instructions. make[2]: *** [libgcc/./_mulsc3.o] Error 1 make[2]: Leaving directory `/home/mcm/projects/llvm/build-gcc4/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/home/mcm/projects/llvm/build-gcc4/gcc' make: *** [all-gcc] Error 2 I know x86_64 is unsupported, but does anybody have an idea if i'm doing something wrong or is this a bug? Any help is greatly appreciated, Marco -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: llvm-gcc4.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060509/1d2b3d18/attachment.ksh> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: x86.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060509/1d2b3d18/attachment-0001.ksh>
On Tue, 9 May 2006, Marco Matthies wrote:> i tried compiling llvmgcc4 on x86_64-linux. The two changes i needed to apply > to llvm and llvmgcc4 are attached. Those two patches tell llvmgcc4 to use the > x86 code-generator for x86_64 and give x86_64-* targets a score of 10 for the > x86 backend when trying to find appropriate backends.Okay, I'll integrate some variant of these changes into my tree. As you mention, x86-64 isn't supported right now. It's highly likely that work will be starting soon on it, but until then, I'd suggest sticking with 32-bit X86. If you configure llvm-gcc with --host=i686-unknown-linux-gnu --target=i686-unknown-linux-gnu (going from memory, may be wrong), you should get a 32-bit compiler that does what you want.> Now i'm getting stuck during the compile when an assertion is triggered: > make[3]: Leaving directory `/home/mcm/projects/llvm/build-gcc4/gcc' > /home/mcm/projects/llvm/build-gcc4/gcc/xgcc > -B/home/mcm/projects/llvm/build-gcc4/gcc/ > -B/home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/bin/ > -B/home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/lib/ -isystem > /home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/include > -isystem > /home/mcm/projects/llvm/install-gcc4/x86_64-unknown-linux-gnu/sys-include -O2 > -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. > -I../../2006-05-08-llvm-gcc-4/gcc -I../../2006-05-08-llvm-gcc-4/gcc/. > -I../../2006-05-08-llvm-gcc-4/gcc/../include > -I../../2006-05-08-llvm-gcc-4/gcc/../libcpp/include > -I/home/mcm/projects/llvm/build-release/../llvm-cvs/include > -I/home/mcm/projects/llvm/build-release/include -DL_mulsc3 > -fvisibility=hidden -DHIDE_EXPORTS -c > ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c -o libgcc/./_mulsc3.o > cc1: > /home/mcm/projects/llvm/build-release/../llvm-cvs/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:2826: > llvm::SDOperand <unnamed>::SelectionDAGLegalize::PromoteOp(llvm::SDOperand): > Assertion `getTypeAction(VT) == Promote && "Caller should expand or legalize > operands that are not promotable!"' failed. > ../../2006-05-08-llvm-gcc-4/gcc/libgcc2.c:1714: internal compiler error:Interesting. Since you're using the 32-bit backend, this is a bug in the 32-bit backend, even if it's being misused. Can you copy and paste the above command, adding "-emit-llvm -o x.bc" to the end? Once you do that, running 'llc x.bc -march=x86' should cause the same assertion. If so, please file a bug report in bugzilla and we'll get it fixed. Thanks, -Chris -- http://nondot.org/sabre/ http://llvm.org/
Chris Lattner wrote:> > Hi All, > > There's a new snapshot of llvmgcc4 available here: > > http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gz > > This release includes the various portability fixes contributed on > llvmdev, includes fixes to build with mainline CVS (and, thus, *requires* > mainline CVS), and includes various other bug fixes. > > If you're interested, please try it out.I get this with LLVM CVS: ../../2006-05-08-llvm-gcc-4/gcc/llvm-backend.cpp: In function `void llvm_asm_file_start()': ../../2006-05-08-llvm-gcc-4/gcc/llvm-backend.cpp:150: error: invalid use of undefined type `struct llvm::TargetData' ../../2006-05-08-llvm-gcc-4/gcc/llvm-internal.h:56: error: forward declaration of `struct llvm::TargetData' ../../2006-05-08-llvm-gcc-4/gcc/llvm-backend.cpp:180: error: invalid use of undefined type `struct llvm::TargetData' ../../2006-05-08-llvm-gcc-4/gcc/llvm-internal.h:56: error: forward declaration of `struct llvm::TargetData' ../../2006-05-08-llvm-gcc-4/gcc/llvm-backend.cpp: In function `void emit_global_to_llvm(tree_node*)': ../../2006-05-08-llvm-gcc-4/gcc/llvm-backend.cpp:387: error: `getTypeAlignment' undeclared (first use this function) ../../2006-05-08-llvm-gcc-4/gcc/llvm-backend.cpp:387: error: (Each undeclared identifier is reported only once for each function it appears in.) Adding: #include "llvm/Target/TargetData.h" Fixed this. Then I get: ../../2006-05-08-llvm-gcc-4/gcc/llvm-convert.cpp: In member function `void TreeToLLVM::EmitMemCpy(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)': ../../2006-05-08-llvm-gcc-4/gcc/llvm-convert.cpp:800: error: `getIntPtrType' undeclared (first use this function) Which is fixed in exactly same way. And then the same change in needed in llvm-types.cpp. Chris, any change you'll make gcc4 frontend source available from some CVS? Then, I can put together a script to build it every night, to make sure things are in shape. - Volodya
Chris Lattner wrote:> > Hi All, > > There's a new snapshot of llvmgcc4 available here: > > http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gzChris, is there any chance that the new frontend will support dynamic loading of backends? I.e: llvm-g++ -load my_backend.so -march=my_arch a.c ? Thanks, Volodya
On Sat, 13 May 2006, Vladimir Prus wrote:>> If you're interested, please try it out. > I get this with LLVM CVS: > Adding: > #include "llvm/Target/TargetData.h" > Fixed this.Right, thanks.> Chris, any change you'll make gcc4 frontend source available from some CVS? > Then, I can put together a script to build it every night, to make sure > things are in shape.So far, the only difference is the #includes added above. If you really want, I can make a new tarball, but otherwise, you can use the existing one with a couple of new #includes. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Sat, 13 May 2006, Vladimir Prus wrote:>> There's a new snapshot of llvmgcc4 available here: >> http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gz > > Chris, > is there any chance that the new frontend will support dynamic loading of > backends? I.e: > > llvm-g++ -load my_backend.so -march=my_arch a.cSure, we can add support for whatever we want :). There are two pieces to this, modifying the driver and modifying the compiler to accept the option. I'd suggest looking at how I added the -emit-llvm option as an example. However, what is the goal of this? IS this because you are you rapidly changing your backend, and don't want to recompile it all the time? If so, one technique I use a lot is: $ llvm-gcc -emit-llvm x.c -S -o - | gccas | llc Which obviously doesn't require you to recompile cc1. Another potential option would be to link the target in as a .so file. I'm not sure how much makefile hackery any of these changes would take, but probably not much. Check out how the targets are selected in gcc/Makefile.in -Chris -- http://nondot.org/sabre/ http://llvm.org/