[Bug c/30503] New: ICE using phase 2 bootstrap output cc1 on tree.c

[Bug c/30503] New: ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

Using the phase 2 cc1 on tree.c results in a segmentation error. Phase 1 cc1
does not result in segmentation faults. This is on main at patchlevel 12900.

Command:

/var/tmp/gcc_r43/gcc.build.lnx14/gcc/xgcc -v -save-temps
-B/var/tmp/gcc_r43/gcc.build.lnx14/gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c   -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.3.0/gcc -I../../gcc-4.3.0/gcc/. -I../../gcc-4.3.0/gcc/../include
-I../../gcc-4.3.0/gcc/../libcpp/include  -I../../gcc-4.3.0/gcc/../libdecnumber
-I../libdecnumber    ../../gcc-4.3.0/gcc/tree.c -o tree.o

Output:

Reading specs from /var/tmp/gcc_r43/gcc.build.lnx14/gcc/specs
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v4
--enable-version-specific-runtime-libs --disable-nls --disable-checking
--disable-werror --disable-multilib --disable-libgcj --disable-dssi
--disable-checking --enable-shared --enable-threads=posix --enable-bootstrap
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-cpu=pentium2
--with-system-zlib --enable-clocale=gnu
Thread model: posix
gcc version 4.3.0 20070118 (experimental)
 /var/tmp/gcc_r43/gcc.build.lnx14/gcc/cc1 -E -quiet -v -I. -I.
-I../../gcc-4.3.0/gcc -I../../gcc-4.3.0/gcc/. -I../../gcc-4.3.0/gcc/../include
-I../../gcc-4.3.0/gcc/../libcpp/include -I../../gcc-4.3.0/gcc/../libdecnumber
-I../libdecnumber -iprefix
/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/
-isystem /var/tmp/gcc_r43/gcc.build.lnx14/gcc/include -DIN_GCC -DHAVE_CONFIG_H
../../gcc-4.3.0/gcc/tree.c -mtune=pentium2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute -O2 -fpch-preprocess -o tree.i
ignoring nonexistent directory
"/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc//lib/gcc/i686-pc-linux-gnu/4.3.0/include"
ignoring nonexistent directory
"/var/tmp/gcc_r43/gcc.build.lnx14/gcc/../../../lib/gcc//lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "."
ignoring duplicate directory "../../gcc-4.3.0/gcc/."
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../gcc-4.3.0/gcc
 ../../gcc-4.3.0/gcc/../include
 ../../gcc-4.3.0/gcc/../libcpp/include
 ../../gcc-4.3.0/gcc/../libdecnumber
 ../libdecnumber
 /var/tmp/gcc_r43/gcc.build.lnx14/gcc/include
 /usr/local/include
 /usr/include
End of search list.
 /var/tmp/gcc_r43/gcc.build.lnx14/gcc/cc1 -fpreprocessed tree.i -quiet
-dumpbase tree.c -mtune=pentium2 -auxbase-strip tree.o -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute -version -o tree.s
GNU C version 4.3.0 20070118 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.3.0 20070118 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 43ce5038e422d0a4c380c402a468014e
../../gcc-4.3.0/gcc/tree.c: In function 'int_cst_hash_hash':
../../gcc-4.3.0/gcc/tree.c:8131: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: ICE using phase 2 bootstrap output cc1 on tree.c
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: malitzke at metronets dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

------- Comment #1 from malitzke at metronets dot com  2007-01-18 18:31 -------
Created an attachment (id=12919)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12919&action=view)
Detailed out using different optimization levels

I also have similar output using Phase 1 cc1 (also at different otimization
levels). 
In another attachment I am submitting tree.i.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

------- Comment #2 from malitzke at metronets dot com  2007-01-18 18:38 -------
Created an attachment (id=12920)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12920&action=view)
Standard preprocessed file

This file was created using the xgcc resulting from phase 2. I have another
file tree.i using the phase 1 xgcc this differs on in the includes referenced.
The includes diff equal for phase 1 and 2 (spot checks only) 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

------- Comment #3 from malitzke at metronets dot com  2007-01-18 18:52 -------
Prior to patclevel 12900 (about 12880) bootstrap failed even with O1 with
segment error.

For those dismissive folks who either say "It works for me" or claim that it is
the submitters harware fault I can only aver the following:
The work was done on a four processor server with 3G error correcting memory
and    over the last three weeks similar Segmentation errors occured; I have
tried different binutils and different versions of glibc. 

I realize GCC-main is undergoing drastic changes right now. 

day before yesterday cc1 (from phse 1) worked with O1 and bombed out with O2. 
I doubt this cand be reduced to a simple test case as it occurs when trying to 
optimize across procedures. 

Glad to cooperate further. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug c/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

------- Comment #4 from malitzke at metronets dot com  2007-01-18 23:40 -------
Well , the mistery continues.
First when I referred to patchlevels I left out a 0 (zero); 12900 should read
120900.
Second I repeated the bootstrap because a number of patches from Daniel Berlin
looked promising to me. Now instead o just hanging at "checking for
i686-pc-linux-gnu-pcc" in gearing up for pass 3 in "i686-pc-linux-gnu/libgcc"
it allocated itself 2.7G of memory before going on to "checking for suffix of
object files ..." it grabbed 2.8 G memory of my 3+G and issued "configure:
error: cannot compute suffix of objectfiles: cannot compile. 
The memory grabbing was checked with the utility "top".

Checking cc1 with tree.i gave essentially the same results as before. I could
send in the details if wanted.


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-01-18 23:45 -------
Are you sure you don't have bad memory?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

------- Comment #6 from malitzke at metronets dot com  2007-01-19 00:20 -------
Mr Pinski 
I do not appreciate your comment. My comment 3 was really addressed to people
like you who want to garner points as beiong the big killers of problem reports
by using cheap tactics. With four processors and 3 Gigabytes of error
correcting menory it is highly unlikely that  the test cases I ran  started
each time at the same location to cause consistently repeatable failures.
Remember what a fellow gcc.gnu.org mantainer recently said about your attitude.
I can only aver that he was right. I was hoping you would have learned a
lesson. You actually used a PR I filed about glibc to make a point like this
one to the glibc people. If you want a flame war let me say that have collected
a number of cases concerning your behaviour.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2007-01-19 00:24 -------
(In reply to comment #6)
> Mr Pinski 
> I do not appreciate your comment. 

But my point was I know if you having hardware issues you will have some issues
with segfaults and other random internal compiler errors.  In fact my machine
overheats all the time and I get a random segfault.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[dberlin at gcc dot gnu dot org]

------- Comment #8 from dberlin at gcc dot gnu dot org  2007-01-19 03:55 -------
Okay, well, this is pretty simple.
If we can't reproduce the bug (and i can't, and andrew can't), we can't fix it.
So this bug is just going to stay open forever until then, regardless of
whether it's a hardware failure, a kernel bug, or a gcc bug.


-- 

dberlin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|dberlin at gcc dot gnu dot  |
                   |org                         |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |build


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[malitzke at metronets dot com]

------- Comment #9 from malitzke at metronets dot com  2007-04-02 20:39 -------
I believe this report can be closed. I was able to find the start date
(2061125)
or a day later when I could no longer bootstrap. It disappeared towards the end
of January 2007. It prevented bootstrapping on x86 but not on powerpc. It has
not reappeared and was consistent on three x86 machines. 
It seems that many maintainers ar not doing the complete (and quite time
consuming bootstrapping) during the non-regression period. 


-- 

malitzke at metronets dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503

[Bug middle-end/30503] ICE using phase 2 bootstrap output cc1 on tree.c

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2007-04-02 22:13 -------
> It seems that many maintainers ar not doing the complete (and quite time
> consuming bootstrapping) during the non-regression period. 

I think that is wrong as most are, just some forgot to double check.  Like at
one point -fkeep-inline-functions were broken so if someone bootstrapped their
patch before that and posted it and then applied after that was fixed, you
would get a bootstrap failure.

Also I and many others actually bootstrap on many different targets all the
time.  I do powerpc64-linux-gnu and i686-linux-gnu as those are the two
machines I have access to (well and a cross to spu-elf).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30503