New llvmgcc4 snapshot

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

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:Bug Reporting - Apple Developer> 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

llvm-gcc4.patch (556 Bytes)

x86.patch (1.07 KB)

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

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

?

Thanks,
Volodya

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

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

-Chris

Chris Lattner wrote:

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

Cheers,

-- Jim

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.

Reid.