llvm-gcc bootsrtap on ARM

Hello,

I am trying to bootstrap on ARM linux EABI using a qemu chroot to
better test my changes on at least one more architecture.

I am using the following configure line:

../gcc/configure --prefix=/home/espindola/install/
--program-prefix=llvm- --enable-languages=c --disable-shared
--disable-multilib --enable-llvm=/home/espindola/build
--enable-checking arm-linux-gnueabi

The bootstrap fails in the most annoying point possible, a compare
difference between arm.o in stages 2 and 3.

Before I try a manual bootstrap (compile gcc 3 times from scratch),
has someone succeeded is doing a similar bootstrap recently? What
version of llvm, llvm-gcc and qemu have you used?

Thanks,

Hello,

I am trying to bootstrap on ARM linux EABI using a qemu chroot to
better test my changes on at least one more architecture.

I am using the following configure line:

../gcc/configure --prefix=/home/espindola/install/
--program-prefix=llvm- --enable-languages=c --disable-shared
--disable-multilib --enable-llvm=/home/espindola/build
--enable-checking arm-linux-gnueabi

The bootstrap fails in the most annoying point possible, a compare
difference between arm.o in stages 2 and 3.

Ouch. That's not pleasant. This probably means cc1 is miscompiled. If you are able to narrow it down to which .o file is miscompiled you can let bugpoint grind it out for you. Use the good arm.s as --output argument, specify all the .o files and .a files as part of link line, etc.

Evan

Interesting. Evan and I were seeing a similar miscompare (on a
different file, obviously) on x86 Darwin about 2 weeks ago. In our
case it went away with patch 43367, so I haven't pursued figuring
out what the problem was, but it's quite possible that patch just hid
the problem instead of fixing it.

In our case the difference in the files was only about 10 instructions,
and both versions were functionally correct. It appeared the induction
variable code was making a different choice in a case where it could
have used either of 2 induction variables. Could you diff your .o's and
see if this looks like the same problem?

Rafael,

Remember that the qemu <= 0.9.0 can misexecute code compiled by LLVM.
I think you should test using qemu CVS.

Lauro

I forgot that the qemu CVS cannot run ARM EABI programs. So, who wants
to run LLVM compiled ARM EABI programs should use the Mamona qemu.

http://dev.openbossa.org/trac/mamona/wiki/QEmuInstallationGuide

Lauro