Re: egcs-1.1b bootstrap comparison failure, i386-pc-solaris2.7

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

  In message <199810120420.VAA02792@junta.eng.sun.com>you write:
  > I tried compiling egcs 1.1b on a local Intel machine here.  I used the
  > 	# workaround for "make install" problem, see below
  > 	(
  > 	  mkdir -p gcc/f
  > 	  cd gcc/f
  > 	  ln -s ../../../dist/gcc/f/ansify.c ansify.c
  > 	  ln -s ../../../dist/gcc/f/intdoc.c intdoc.c
  > 	  ln -s ../../../dist/gcc/f/intdoc.in intdoc.in
  > 	  ln -s ../../../dist/gcc/f/intdoc.texi intdoc.texi
  > 	  ln -s ../../../dist/gcc/f/intrin.c intrin.c
  > 	  ln -s ../../../dist/gcc/f/intrin.def intrin.def
  > 	  ln -s ../../../dist/gcc/f/intrin.h intrin.h
  > 	)
Use gnu-make and I think this problem will go away.



  > I disassembled the object files, and diff'ed them, and most of them were
  > quite similar.  The only difference in g++.o, for example, is:
  > 
  > 	2691,2693c2690,2692
  > 	<       2360:  66 0f b6 5d bf         movzbw -0x41(%ebp),%bx
  > 	<       2365:  66 0f b6 05 00 00 00 00 movzbw 0x0,%ax
  > 	<       236d:  66 89 85 64 ff ff ff   movw   %ax,-0x9c(%ebp)
  > 	---
  > 	>       2360:  66 0f b6 05 00 00 00 00 movzbw 0x0,%ax
  > 	>       2368:  66 89 85 64 ff ff ff   movw   %ax,-0x9c(%ebp)
  > 	>       236f:  66 0f b6 5d bf         movzbw -0x41(%ebp),%bx
  > 
  > "f/data.o" had a couple more things, and "f/target.o" had a large number
  > of differences.  I haven't pored over the disassembly of "f/target.o" to
  > see if any of the differences are meaningful, nor would I like to.  If
  > it would be helpful, I can put up the object files, or the disassembled
  > object files, to look at.
This is potentially very serious.  It is impossible to tell how serious
without doing a full analysis.

Unfortunately, I don't have access to any x86-solaris2.7 machines, so I can
not debug it myself.

So, you'll need to debug it.

The first step (of course) is to verify that the problem is reproducible.  If
you can't reproduce the problem, then it's going to be all but impossible to
debug.

The second step is to select one of these failures to analyze:

	Bootstrap comparison failure!
	g++.o differs
	g77.o differs
	gcc.o differs
	f/data.o differs
	f/target.o differs



Typically I select the one with smallest .o file.  You'll need cpp output for
the failing module.  You can get this by adding -save-temps to the command line
which was used to compile the failing module.  This will have a .i file like
g77.i.

Then you want to do something like

stage1/cc1 -O2 -g g77.i -o foo.s
stage2/cc1 -O2 -g g77.i -o bar.s

The .s files should be different.

The next step will be to add "-dap" to those command lines which force the
compiler to emit debugging dumps.  You'll want to compare the debugging dumps
and find the first one that is different.

Once you get to that stage, contact me again :-)

jeff