Bug 6680 - [3.3 only] genattrtab crashes on tru64 5.0
Summary: [3.3 only] genattrtab crashes on tru64 5.0
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build
: 9899 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-05-16 08:26 UTC by sabelka
Modified: 2003-12-16 20:17 UTC (History)
4 users (show)

See Also:
Host: alphaev5-dec-osf5.0
Target: alphaev5-dec-osf5.0
Build: alphaev5-dec-osf5.0
Known to work:
Known to fail:
Last reconfirmed: 2003-06-25 17:39:34


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sabelka 2002-05-16 08:26:14 UTC
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
Comment 1 Wolfgang Bangerth 2002-12-05 15:37:24 UTC
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.
 

Comment 2 Wolfgang Bangerth 2002-12-06 09:16:08 UTC
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.
 

Comment 3 Dara Hazeghi 2003-05-21 01:21:44 UTC
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
 
Comment 4 Christian Ehrhardt 2003-05-21 09:41:41 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: See Dara's question.
Comment 5 Dara Hazeghi 2003-06-20 23:44:39 UTC
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.
Comment 6 sabelka 2003-06-25 15:16:10 UTC
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



Comment 7 Dara Hazeghi 2003-06-25 17:37:06 UTC
*** Bug 9899 has been marked as a duplicate of this bug. ***
Comment 8 Dara Hazeghi 2003-06-25 17:39:34 UTC
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.
Comment 9 sabelka 2003-07-10 05:12:17 UTC
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 
 
 
Comment 10 Dara Hazeghi 2003-07-10 06:20:21 UTC
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
Comment 11 Andrew Pinski 2003-08-10 03:45:25 UTC
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.
Comment 12 Mark Mitchell 2003-09-17 21:46:21 UTC
Postponed again -- this is not a primary platform, and there is no sign of progress.
Comment 13 Andrew Pinski 2003-10-19 21:57:15 UTC
Closing as fixed on the mainlne because it works there and there is most likely not going 
to be a 3.3.3 release.
Comment 14 Andrew Pinski 2003-10-23 16:48:17 UTC
Reopening based on there is going to be a 3.3.3 release.
Comment 15 Andrew Pinski 2003-12-16 20:17:09 UTC
No signs of this getting fixed for 3.3.x so closing as fixed for 3.4