Help tracing an internal compiler error

[Warren_Baird at cimmetry dot com]

Hi all,

I'm looking for some advice on how to track down an internal compiler
error.  We upgraded to gcc-3.3.1 a few weeks ago, and I just tried my
first build with -O2 and -g both turned on.  I ended up getting
internal compiler errors in a number of places.  I've done some
experiments, and the only thing I can determine is that the ICE seems
to be related in some way to the length of the preprocessed file.  I
can make the ICE go away by removing about 15 lines of code from the
end of a huge file, and then make it appear again by adding 15
completely different lines of code back into the file.

I haven't been able to create a file that exhibits this behaviour and
doesn't also contain a lot of proprietary information, so I can't
really open a bug report yet.  But I'd really appreciate any advice
people might have on what is going on here, or on how I might
construct a test case that repro's the problem.  My instinct is that
there is some kind of a table overflow happening --- is there any way
to verify this?

More details follow:


I started with a preprocessed version of the file generating the ICE,
and started trying to chop things out to find a minimal file that
repros the problem.  I soon had 3 variants of the file, called tmp1.ii,
tmp2.ii and tmp3.ii.

  - tmp1.ii was the smallest file I found that generated the ICE (It's
  about 110,000 lines long)

  - tmp2.ii was a copy of tmp1.ii with the last struct in the file
  removed --- it was a 15 line long struct from freetype.  tmp2.ii
  compiles without any errors

  - tmp3.ii was a copy of tmp2.ii with 5 copies of a simple 1 line
  function added where the freetype struct was.  It also generates an
  ICE.

Here are the diffs between the files:

   diff -u tmp1.ii tmp2.ii
--- tmp1.ii     Thu Sep  4 14:29:41 2003
+++ tmp2.ii     Thu Sep  4 14:34:04 2003
@@ -110740,21 +110740,6 @@
 # 1 "src/support/freetype/include/freetype/t1tables.h" 1
 # 28 "src/support/freetype/include/freetype/t1tables.h"
 extern "C" {
-# 63 "src/support/freetype/include/freetype/t1tables.h"
-  typedef struct PS_FontInfoRec
-  {
-    FT_String* version;
-    FT_String* notice;
-    FT_String* full_name;
-    FT_String* family_name;
-    FT_String* weight;
-    FT_Long italic_angle;
-    FT_Bool is_fixed_pitch;
-    FT_Short underline_position;
-    FT_UShort underline_thickness;
-
-  } PS_FontInfoRec, *PS_FontInfo;
-# 88 "src/support/freetype/include/freetype/t1tables.h"

--- tmp2.ii     Thu Sep  4 14:34:04 2003
+++ tmp3.ii     Thu Sep  4 14:36:01 2003
@@ -110741,6 +110741,24 @@
 # 28 "src/support/freetype/include/freetype/t1tables.h"
 extern "C" {

+       void myFunc1(int a) {
+          float b = 5;
+}

+       void myFunc2(int a) {
+          float b = 5;
+}

+       void myFunc3(int a) {
+          float b = 5;
+}
+
+       void myFunc4(int a) {
+          float b = 5;
+}
+
+
+       void myFunc5(int a) {
+          float b = 5;
+}
 }

Other bits of info: I'm doing this on a solaris 8 machine: "gcc -c -v
-g -O2 tmp1.ii" says:

Reading specs from
/usr/local/gcc-3.3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/specs
Configured with: ../gcc-3.3.1/configure --prefix=/usr/local/gcc-3.3.1
--with-gnu-as --with-gnu-ld --with-gnu-nm
--with-as=/usr/local/binutils-2.13.2.1/bin/as
--with-ld=/usr/local/binutils-2.13.2.1/bin/ld
--with-nm=/usr/local/binutils-2.13.2.1/bin/nm
Thread model: posix
gcc version 3.3.1
 /usr/local/gcc-3.3.1/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/cc1plus
-fpreprocessed tmp1.ii -quiet -dumpbase tmp1.ii -auxbase tmp1 -g -O2 -version -o
/var/tmp//ccTZyWKm.s
GNU C++ version 3.3.1 (sparc-sun-solaris2.8)
        compiled by GNU C version 3.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[ various compiler warnings removed ]
/usr/local/gcc-3.3.1/include/c++/3.3.1/bits/basic_string.tcc:288: 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.

If I just use -g, or I just use -O2, it compiles fine --- it only
fails if I use -g -O2.  If I compile the same code gcc-3.2.2, it works
fine.  Also, the original code compiles fine on linux with gcc-3.3.1.


We may have to fall back to gcc-3.2 for the moment, but I'd really
like to be able to submit a useful bug report, so if anyone has any
suggestions on how to pin this one down more so I can produce a
repro-able testcase, I'd love to hear it!

Thanks,

Warren