The stage2 compiler fails with an internal error when compiling the file predict.c Here are the last few lines of the "make bootstrap" output: stage2/xgcc -Bstage2/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.1/gcc -I../../gcc-3.1/gcc/. -I../../gcc-3.1/gcc/config -I../../gcc-3.1/gcc/../include ../../gcc-3.1/gcc/optabs.c -o optabs.o ../../gcc-3.1/gcc/optabs.c: In function `expand_binop': ../../gcc-3.1/gcc/optabs.c:1221: warning: comparison between signed and unsigned ../../gcc-3.1/gcc/optabs.c:1223: warning: signed and unsigned type in conditional expression ../../gcc-3.1/gcc/optabs.c:1236: warning: comparison between signed and unsigned ../../gcc-3.1/gcc/optabs.c:1257: warning: comparison between signed and unsigned stage2/xgcc -Bstage2/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.1/gcc -I../../gcc-3.1/gcc/. -I../../gcc-3.1/gcc/config -I../../gcc-3.1/gcc/../include ../../gcc-3.1/gcc/params.c -o params.o stage2/xgcc -Bstage2/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.1/gcc -I../../gcc-3.1/gcc/. -I../../gcc-3.1/gcc/config -I../../gcc-3.1/gcc/../include ../../gcc-3.1/gcc/predict.c -o predict.o ../../gcc-3.1/gcc/predict.c: In function `propagate_freq': ../../gcc-3.1/gcc/predict.c:708: Internal compiler error in @ @, at F:537438864 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. gmake[2]: *** [predict.o] Error 1 gmake[2]: Leaving directory `/a61/tmp/tmp-saba/gcc-3.1-build-osf/gcc' gmake[1]: *** [stage3_build] Error 2 gmake[1]: Leaving directory `/a61/tmp/tmp-saba/gcc-3.1-build-osf/gcc' gmake: *** [bootstrap] Error 2 Maybe this internal error is caused by an optimization bug. I was able to bootstrap successfully without optimization (BOOT_CFLAGS=-g)! Release: gcc-3.1 Environment: DEC Alpha EV5 Digital UNIX V5.0 (Rev. 910); Mon May 15 21:08:33 CEST 2000 How-To-Repeat: ../gcc-3.2/configure make bootstrap
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: bootstrap/6680: [alphaev5-dec-osf5.0] gcc-3.1 build fails with internal error Date: Thu, 5 Dec 2002 15:37:24 -0600 (CST) The following mail caused me to close all the duplicates listed below, except 6680. For the record, I send this mail to the audit trail of 6680. W. ---------- Forwarded message ---------- Date: Thu, 5 Dec 2002 10:54:36 +0100 From: Emmanuel Thomé <thome@lix.polytechnique.fr> To: Wolfgang Bangerth <bangerth@ticam.utexas.edu> Subject: Re: ICE/bootstrap alpha*-dec-osf5.0 OK, I'll contact the persons you mention. > > P.S: Perhaps most if not all of these PR's could be collapsed to a > > single one ? > > [...] > > Oh yes, I would be happy to do this. Can you indicate which of these I can > close and which other report I should reference in the closing message? > The bug database has become so large that it has become nearly unusable, > and it is really necessary to reduce same cases to only one > representative. Then I'm 100% sure that PRs # 6680, 6766, 7509, 7626, 7747, 7777, 8452, 6796 are duplicates of the same bug. The six other PRs I mention in my mail might be related to the same issue, but that's unclear. So this makes for 8 PRs that you can collapse into a single one ! None of them is significantly more accurate than the others, so picking a random one would do. Perhaps the one PR that you keep should include a reference to the ones that have been closed. Greetings, E.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: bootstrap/6680: [alphaev5-dec-osf5.0] gcc-3.1 build fails with internal error Date: Fri, 6 Dec 2002 09:16:08 -0600 (CST) This valuable piece of information may get things going on osf50. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth ---------- Forwarded message ---------- Date: Fri, 6 Dec 2002 10:27:12 +0100 From: Emmanuel Thomé <thome@lix.polytechnique.fr> To: Wolfgang Bangerth <bangerth@ticam.utexas.edu> Subject: Re: ICE/bootstrap alpha*-dec-osf5.0 The build process completes with -fno-reorder-blocks passed as BOOT_CFLAGS ; Rainer Sabelka found this, he is currently ttrying to investigate things further. E.
From: Dara Hazeghi <dhazeghi@yahoo.com> To: sabelka@iue.tuwien.ac.at, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: bootstrap/6680: [alphaev5-dec-osf5.0] gcc-3.1 build fails with internal error Date: Wed, 21 May 2003 01:21:44 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=6680 Hello, would it be possible for you to check whether the problem in this report still occurs with the most current version of gcc (3.3) or the cvs 3.3 branch? I believe some progress has been made in this area. Thanks, Dara
State-Changed-From-To: open->feedback State-Changed-Why: See Dara's question.
Just a reminder that this bug is waiting for your feedback. Can you confirm whether this problem is still present with gcc 3.3? If the internal compiler error is still occuring, preprocessed source demonstrating the problem would be nice. Thanks.
Subject: Re: [alphaev5-dec-osf5.0] gcc-3.1 build fails with internal error I tried to compile gcc-3.3 now, but still without success. This time the failure shows up on a different location. Here are last few lines of the gmake output: stage1/xgcc -Bstage1/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.3/gcc -I../../gcc-3.3/gcc/. -I../../gcc-3.3/gcc/config -I../../gcc-3.3/gcc/../include ../../gcc-3.3/gcc/ifcvt.c -o ifcvt.o stage1/xgcc -Bstage1/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../gcc-3.3/gcc -I../../gcc-3.3/gcc/. -I../../gcc-3.3/gcc/config -I../../gcc-3.3/gcc/../include ../../gcc-3.3/gcc/genattrtab.c -o genattrtab.o stage1/xgcc -Bstage1/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I../../gcc-3.3/gcc -I../../gcc-3.3/gcc/. -I../../gcc-3.3/gcc/config -I../../gcc-3.3/gcc/../include ../../gcc-3.3/gcc/genautomata.c -o genautomata.o stage1/xgcc -Bstage1/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -I. -I. -I../../gcc-3.3/gcc -I../../gcc-3.3/gcc/. -I../../gcc-3.3/gcc/config -I../../gcc-3.3/gcc/../include ../../gcc-3.3/gcc/varray.c -o varray.o stage1/xgcc -Bstage1/ -B/usr/local/alphaev5-dec-osf5.0/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE -o genattrtab \ genattrtab.o genautomata.o \ rtl.o read-rtl.o bitmap.o ggc-none.o gensupport.o insn-conditions.o print-rtl1.o errors.o \ varray.o ../libiberty/libiberty.a -lm ./genattrtab ../../gcc-3.3/gcc/config/alpha/alpha.md > tmp-attrtab.c Check description...done Reservation transformation...done Create automaton `ev4_0'...genattrtab: Internal error: /bin/sh: 141655 Memory fault gmake[2]: *** [s-attrtab] Error 139 gmake[1]: *** [stage2_build] Error 2 gmake[2]: Leaving directory `/amd/in14/root/export/users2/sabelka/src/gcc-3.3-OSF1-V5.0/gcc' gmake: *** [bootstrap] Error 2 gmake[1]: Leaving directory `/amd/in14/root/export/users2/sabelka/src/gcc-3.3-OSF1-V5.0/gcc' Then, I tried to debug the crashing executable: sabelka@a61:~/src/gcc-3.3-OSF1-V5.0/gcc$ gdb genattrtab GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alphaev5-dec-osf5.0"... Breakpoint 1 at 0x12002ff78: file ../../gcc-3.3/gcc/errors.c, line 136. Breakpoint 2 at 0x3ff800d7b20 Breakpoint 3 at 0x3ff80189070 (gdb) r ../../gcc-3.3/gcc/config/alpha/alpha.md Starting program: /amd/in14/root/export/users2/sabelka/src/gcc-3.3-OSF1-V5.0/gcc/genattrtab ../../gcc-3.3/gcc/config/alpha/alpha.md Breakpoint 2 at 0x3ff800d7b24 Breakpoint 3 at 0x3ff80189074 /* Generated automatically by the program `genattrtab' from the machine description file `md'. */ Check description...done Reservation transformation...done Create automaton `ev4_0'... Breakpoint 1, fancy_abort (file=0x1400cc010 "\006", line=1074578672, func=0x600 <Error reading address 0x600: Invalid argument>) at ../../gcc-3.3/gcc/errors.c:136 136 internal_error ("abort in %s, at %s:%d", func, file, line); (gdb) bt #0 fancy_abort (file=0x1400cc010 "\006", line=1074578672, func=0x600 <Error reading address 0x600: Invalid argument>) at ../../gcc-3.3/gcc/errors.c:136 #1 0x1200174a8 in reserv_sets_eq (reservs_1=0x1400cc010, reservs_2=0x1400cc4f0) at ../../gcc-3.3/gcc/genautomata.c:3684 #2 0x120018268 in insert_state (state=0x600) at ../../gcc-3.3/gcc/genautomata.c:4050 (gdb) up #1 0x1200174a8 in reserv_sets_eq (reservs_1=0x1400cc010, reservs_2=0x1400cc4f0) at ../../gcc-3.3/gcc/genautomata.c:3684 3684 { (gdb) l 3679 /* The function checks equality of the reservation sets. */ 3680 static int 3681 reserv_sets_eq (reservs_1, reservs_2) 3682 reserv_sets_t reservs_1; 3683 reserv_sets_t reservs_2; 3684 { 3685 return reserv_sets_cmp (reservs_1, reservs_2) == 0; 3686 } 3687 3688 /* Set up in the reservation set that unit with UNIT_NUM is used on (gdb) quit The program is running. Exit anyway? (y or n) y For me it's not clear why the function fancy_abort() gets called (with obviously invalid parameters on the stack). So it seems that either the stage1 gcc or some other component (osf1 assembler/linker) is generating invalid code. As with previous versions of gcc I was able to build the compiler successfully with BOOT_CFLAGS="-g -O -fno-reorder-blocks" Cheers, Rainer
*** Bug 9899 has been marked as a duplicate of this bug. ***
Okay, so this is the same problem as in PR 9899. Supposedly, this problem is fixed with mainline. If someone could figure out which patch in fact fixed this, then it's probable the fix can be applied to the 3.3 branch as well.
I tried to find out when this bug was fixed in the main line by compiling cvs versions from various dates (cvs update -D ....). Here is what I've found out: 2003-03-06: compiling fails with the genattrtab bug (like most version before this date). 2003-03-07: failure during compilation of libstdc++: xgcc: Internal error: Segmentation fault (program cc1plus) 2003-03-08: like 2003-03-07 2003-03-09: success So it seems the bug has been corrected between March 6th and 8th. Maybe this info helps you to find the correct patch for backporting to the 3.3 branch. -Rainer
Wow, thanks for narrowing this down! I took a look at the gcc-cvs mailing list archives but didn't seen anything particularly obvious. The things that look possibly connected are Richard Kenner's patch to alpha.md and others, and Roger's patch for emit-rtl.c. Oh, and this patch, claims to be Itanium only, but seems to deal exactly with the issue of block reording (and deals with generic code in the scheduler): http://gcc.gnu.org/ml/gcc-patches/2003-03/msg00583.html Cheers, Dara
Move to target to 3.3.2 as this only effects 3.3 as the mainline has been fixed. The comments neared it down to the day where it was fixed but nothing has come about after that.
Postponed again -- this is not a primary platform, and there is no sign of progress.
Closing as fixed on the mainlne because it works there and there is most likely not going to be a 3.3.3 release.
Reopening based on there is going to be a 3.3.3 release.
No signs of this getting fixed for 3.3.x so closing as fixed for 3.4