llvm-gcc build fail on RHEL v4 x86_64

The machine is a Dell workstation with xeon processors. The OS is RHEL 4 AS x86_64
gcc version is 3.4.6

I checked out the llvm-gcc from svn, configured with
…/llvm-gcc/configure --prefix=$HOME/llvm-gcc-install --enable-llvm=$HOME/llvmobj/ --enable-languages=c,c++ --enable-checking --disable-shared --disable-multilib

and get the following error message:

make GCC_FOR_TARGET="/home/xzx/llvm-gcc-obj/gcc/xgcc -B/home/xzx/llvm-gcc-obj/gcc/ -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/bin/ -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/lib/ -isystem /home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/include -isystem /home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/sys-include"
AR_FOR_TARGET=“ar”
AR_CREATE_FOR_TARGET=“ar rc”
AR_EXTRACT_FOR_TARGET=“ar x”
AR_FLAGS_FOR_TARGET=""
CC=“gcc” CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common "
BUILD_PREFIX=""
BUILD_PREFIX_1=“loser-”
LANGUAGES=""
LIBGCC2_CFLAGS="-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 "
MULTILIB_CFLAGS="" T= crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
make[3]: Entering directory /home/xzx/llvm-gcc-obj/gcc' make[3]: crtbegin.o’ is up to date.
make[3]: crtend.o' is up to date. make[3]: crtbeginS.o’ is up to date.
make[3]: crtendS.o' is up to date. make[3]: crtbeginT.o’ is up to date.
make[3]: Leaving directory /home/xzx/llvm-gcc-obj/gcc' /home/xzx/llvm-gcc-obj/gcc/xgcc -B/home/xzx/llvm-gcc-obj/gcc/ -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/bin/ -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/lib/ -isystem /home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/include -isystem /home/xzx/llvm-gcc-install/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../../llvm-gcc/gcc -I../../llvm-gcc/gcc/. -I../../llvm-gcc/gcc/../include -I../../llvm-gcc/gcc/../libcpp/include -I/home/xzx/llvm/include -I/home/xzx/llvmobj//include -DL_lshrdi3 -c ../../llvm-gcc/gcc/libgcc2.c -o libgcc/./_lshrdi3.o WARNING: 128-bit integers not supported! ../../llvm-gcc/gcc/libgcc2.c: In function '__lshrti3': ../../llvm-gcc/gcc/libgcc2.c:412: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <[URL:http://llvm.org/bugs](http://llvm.org/bugs)> for instructions. make[2]: *** [libgcc/./_lshrdi3.o] Error 1 make[2]: Leaving directory /home/xzx/llvm-gcc-obj/gcc’
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/xzx/llvm-gcc-obj/gcc’
make: *** [install-gcc] Error 2

And after I run
make install
I get only c++ and g++ in my llvm-gcc-install directory.

gcc 3.4.x builds LLVM incorrectly on x86_64.

gcc 4.0 will get you much farther, but the llvm-test regression tests still have massive problems.

Zhongxing Xu wrote:

gcc 3.4.x builds LLVM incorrectly on x86_64.

gcc 4.0 will get you much farther, but the llvm-test regression tests
still have massive problems.

Zhongxing Xu wrote:
> The machine is a Dell workstation with xeon processors. The OS is RHEL
> 4 AS x86_64
> gcc version is 3.4.6
>
> I checked out the llvm-gcc from svn, configured with
> ../llvm-gcc/configure --prefix=$HOME/llvm-gcc-install
> --enable-llvm=$HOME/llvmobj/ --enable-languages=c,c++
> --enable-checking --disable-shared --disable-multilib

You should probably also: --disable-threads --disable-nls

>
> and get the following error message:
>
> make GCC_FOR_TARGET="/home/xzx/llvm-gcc-obj/gcc/xgcc
> -B/home/xzx/llvm-gcc-obj/gcc/
> -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/bin/
> -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/lib/ -isystem
> /home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/include -isystem
> /home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/sys-include" \
> AR_FOR_TARGET="ar" \
> AR_CREATE_FOR_TARGET="ar rc" \
> AR_EXTRACT_FOR_TARGET="ar x" \
> AR_FLAGS_FOR_TARGET="" \
> CC="gcc" CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -fno-common " \
> BUILD_PREFIX="" \
> BUILD_PREFIX_1="loser-" \
> LANGUAGES="" \
> LIBGCC2_CFLAGS="-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 " \
> MULTILIB_CFLAGS="" T= crtbegin.o crtend.o crtbeginS.o crtendS.o
> crtbeginT.o
> make[3]: Entering directory `/home/xzx/llvm-gcc-obj/gcc'
> make[3]: `crtbegin.o' is up to date.
> make[3]: `crtend.o' is up to date.
> make[3]: `crtbeginS.o' is up to date.
> make[3]: `crtendS.o' is up to date.
> make[3]: `crtbeginT.o' is up to date.
> make[3]: Leaving directory `/home/xzx/llvm-gcc-obj/gcc'
> /home/xzx/llvm-gcc-obj/gcc/xgcc -B/home/xzx/llvm-gcc-obj/gcc/
> -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/bin/
> -B/home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/lib/ -isystem
> /home/xzx/llvm-gcc-install/x86_64-unknown-linux-gnu/include -isystem
> /home/xzx/llvm-gcc-install/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../../llvm-gcc/gcc -I../../llvm-gcc/gcc/.
> -I../../llvm-gcc/gcc/../include
> -I../../llvm-gcc/gcc/../libcpp/include -I/home/xzx/llvm/include
> -I/home/xzx/llvmobj//include -DL_lshrdi3 -c
> ../../llvm-gcc/gcc/libgcc2.c -o libgcc/./_lshrdi3.o
> WARNING: 128-bit integers not supported!

This might be the result of the subsequent segv ?

As well as on Alpha. I think that version of gcc should just be
marked as broken.

On alpha (and x86 when using old gccs), the register allocator has
memory leaks that don't exist on builds by more current gccs.

Andrew

gcc 3.4.x builds LLVM incorrectly on x86_64.

gcc 4.0 will get you much farther, but the llvm-test regression tests
still have massive problems.

Please file bug reports on these. Thanks!

Evan

Already have concerning gcc 3.4: http://llvm.org/bugs/show_bug.cgi?id=1056

As for llvm-test issues, quite frankly I don't know how well they're expected to work on x86_64. No one has jumped in and said they run fine on their x86_64 system. Maybe they're code generator bugs, or maybe they're portability issues for FreeBSD (though I never saw such massive problems with 32-bit FreeBSD when I last ran that). I already fixed one problem I found with some shell scripts. The remaining failures do not have an obvious cause, or even clear if it's a single cause. There are 280 "FAILED!" messages altogether.

It's also not clear if gcc 4.0 could still be a source of problems. 4.1 is known to be bad also, after all. Is there a version known to be good? 4.2, 4.3?

Evan Cheng wrote:

I do all my LLVM stuff on x86_64 without trouble… I have a nightly tester up, and its only getting a few regressions currently, and I think some of those have to do with the radical changes going on in LLVM-land currently, and others with no one having done support for x86-64 in debugging output. (this is at least most of what I’ve seen, ymmv).

Also, for the record, I have found both gcc 3.4 and 4.1 to miscompile things with x86-64 and Linux. I think Chris had added this to a readme at one point, but I’m not sure. I do everything with 4.0 and its working fairly well, if not quite as well as x86 / ppc is. =]

-Chandler Carruth

Could you provide a list of all tests failing for you? You can just grep the output from make for 'FAILED!'.

I've fixed 5 of them so far... 275 to go...

Chandler Carruth wrote:

I have 1 regression test failing that is a bug: PR1108

The other two that are failing for me are debug info failures because x86_64 debugging info hasn’t been fully implemented.

As for the full llvm-test suite, I haven’t tried to measure seriously the number of failures in that yet for x86_64, so my numbers there might be very comparable, as I’m sure many of the tests themselves were just not designed to be compatible with the new arch. rock out the fixes on that front! =] (sadly i don’t have any recent logs of a nightly tester run…)

-Chandler