Trunk build failure on Itanium
Janis Johnson
janis187@us.ibm.com
Mon Aug 13 16:15:00 GMT 2001
Hans Boehm wrote on August 9, 2001:
> I've been getting consistent build failures along the following lines for an
> IA64/Linux build of the trunk:
>
> /home/hboehm/gcc/gcc-build/gcc/xgcc -B/home/hboehm/gcc/gcc-build/gcc/
> -B/home/hboehm/gcc/usr/ia64-unknown-linux/bin/
> -B/home/hboehm/gcc/usr/ia64-unknown-linux/lib/ -isystem
> /home/hboehm/gcc/usr/ia64-unknown-linux/include -O2 -DIN_GCC -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include
> -fPIC -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
> -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config
> -I../../gcc/gcc/../include -DL_fixdfdi -c ../../gcc/gcc/libgcc2.c -o
> libgcc/./_fixdfdi.o
> ../../gcc/gcc/libgcc2.c: In function `__fixdfti':
> ../../gcc/gcc/libgcc2.c:958: Internal compiler error in propagate_one_insn,
> at flow.c:5312
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
> make[2]: *** [libgcc/./_fixdfdi.o] Error 1
>
> This occurs for many, but not all, of the functions in libgcc2.c. The
> compilations works fine without the -O2. I believe this is a fairly recent
> regression, though I probably hadn't updated my tree on the IA64 machine for
> a month or so. I updated my tree a second time last night, and the failure
> still occurred then. The same tree builds on X86.
>
> Has anyone else seen this? Any suggestions/insights?
and later that same day he wrote:
> I looked at this (see http://gcc.gnu.org/ml/gcc/2001-08/msg00555.html ) a
> little bit more.
>
> It appears that propagate_one_insn is trying to (erroneously I think) delete
> the instruction that restores ar.pfs before a sibcall. It correctly notices
> the error because sibcall_epilogue_contains(insn) returns 1 .
>
> The preceding call to insn_dead_p returned true because pbi->reg_live failed
> to include ar.pfs, even though it's considered live at the end of the basic
> block. I would guess that the liveness information for ar.pfs is no longer
> propagated correctly through the sibcall?
>
> Could someone who knows this code have a look at this, please?
This problem has existed for at least a month. Andrew Macleod started
discussing possible fixes in gcc-patches and gcc-bugs on July 26, with
feedback from Richard Henderson, but the last mail on the subject was
August 1. The problem still exists today.
Janis
More information about the Gcc
mailing list