Re: problems building egcs-1.0.2 on sparc-sun-solaris2.5.1

[Jeffrey A Law <law at cygnus dot com>]

  In message <356EC411.472E0ABF@eecs.umich.edu>you write:
  > You are correct, I probably did mis-interpret the configure
  > documentation when I said that --enable-haifa was the default. 
  > However... that would seem to be the behavior I am seeing when compiling
  > egcs-1.0.2 for sparc-sun-solaris2.5.1.  I have attached a log from my
  > build attempt below (all 3220 lines of it).  I performed the following
  > actions:
  > 
  > 	% gunzip -c egcs-1.0.2.tar.gz | tar xf -
  > 	% mkdir objdir
  > 	% cd objdir/
  > 	% ../egcs-1.0.2/configure --prefix=/usr/egcs
  > 	% make bootstrap > & make.log
  > 
  > I did not specify a haifa option.  The build failed with a bootstrap
  > comparison failure on cp/class.o.  
  > 
  > The odd thing is that when I run configure with --disable-haifa, the
  > build completes correctly.  (I can send you the other build log if you
  > like).  I did not try to build with --enable-haifa set, but I did find
  > that this failed when I was building the 1.0.1 release.   Which is why I
  > suspected that --enable-haifa was the default.
  > 
  > The 1.0.3 release came out the day I sent my original message.  I was
  > able to build 1.0.3 using the default configure options, as well as with
  > --enable-haifa, without any problems.  So this all may be moot.
Well, based on the log files you included, the system isn't using haifa;
so --disable-haifa shouldn't be making any kind of difference whatsoever.

[ ... ]

  > /usr/gcc/bin/gcc -c  -DIN_GCC  -DSVR4  -g  -DHAVE_CONFIG_H     -I. -I../.=
  > /egcs-1.0.2/gcc -I../../egcs-1.0.2/gcc/config ../../egcs-1.0.2/gcc/sched.c
                                                                       ^^^^^^^^
This is the normal scheduler.  If you had used haifa this would have been
"haifa-sched.c".  There would also have been a -DHAIFA in the compilation
line.

[ ... ]

  > Bootstrap comparison failure!
  > cp/class.o differs
OK.  This means the stage1 and stage2 compilers produced different output
for cp/class.o.  This can happen for a variety of reasons, ranging from non
deterministic behavior in the compiler, other bugs in the compiler, or bugs
in the compiler that you used to bootstrap gcc.

The fact that is seems to come and go would tend to make me think there's
some non-determinism in one of the optimizers.  An uninitialized variable,
reading beyond the end of an array, returning from a non-void function
without a value, etc.

The bad news is these are quite tough to fix since they're often not
reproducable by the folks that know enough about the compiler to identify
the problem.  Usually they sit until a developer runs into the problem
(and thus it's reproducable on their box).

The good news is we're slowing adding code to perform more internal
consistency checking as well as fixing warnings so that we can more
easily identify and fix these kinds of problems.

jeff