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.
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?
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.
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.
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.
Sure, 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
The gcc4 tree is in svn. We believe it should be straight forward to create a public svn image but it will be late next week before we can set it up (minimal svn experience between Chris and myself.)
svn is really easy to use. Much of it is analagous to CVS. You shouldn't
have any problems using it. If you do, feel free to drop me a line. I'd
be glad to help.