Re: problem with gcc-2.95 on Solaris 2.6

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

  In message <Pine.GSO.4.05.9908041219520.19591-100000@spock2>you write:
  > On Tue, 3 Aug 1999, Jeffrey A Law wrote:
  > 
  > > The first step is to get a copy of emit-rtl.i that you can feed into the
  > > stage1 and stage2 compilers.
  > > 
  > > Cut and paste the compile line for last build of emit-rtl.i and add the
  > > "-save-temps" option to it.  That will build emit-rtl.i.
  > 
  > Okay. I used the following to produce emit-rtl.i:
  > 
  > % stage2/xgcc -Bstage2/ -B/opt/local/gnu/sparc-sun-solaris2.6/bin/ -c \
  >   -DIN_GCC -DHAIFA  -DSVR4  -O2 -g  -DHAVE_CONFIG_H    -I. \
  >   -I/tmp/./gcc-2.95/gcc -I/tmp/./gcc-2.95/gcc/config \
  >   -I/tmp/./gcc-2.95/gcc/../include -save-temps /tmp/./gcc-2.95/gcc/emit-rtl
  > .c
  > 
  > > stage1/cc1 -g -O2 emit-rtl.i -o file1
  > > stage2/cc1 -g -O2 emit-rtl.i -o file2
  > 
  > diff -c file1 file2 shows:
  > 
[ ... ]
  > So, it looks like a couple of "sub"s became "add"s. Is
  > this bad?
Thanks.  Yes, this is bad.  As you noted in a followup message we are
mis-compiling operand_subword.


The next step is find out what pass within gcc is messing things up.

To make that process a little easier I suggest you edit your two copies of
emit-rtl.i -- delete everything after the operand_subword function.  Then
rerun the diff test again to verify you still get the differences in the
stage1 and stage2 compiler output.

[ You can continue the process and delete functions before operand_subword too,
  but if it's a memory corruption problem you run a greater risk of making
  the bug mysteriously go away, so checkpoint your work often. ]

At this point I typically do something like
cp emit-rtl.i file1.i
cp emit-rtl.i file2.i

stage1/cc1 -g -O2 -dap file1.i
stage2/cc1 -g -O2 -dap file2.i

This is going to create a bunch of new files which are debugging dumps from
the various passes in the compiler.  But before you look at them, verify that
file1.s and file2.s still have the sub/add difference.

Assuming that the assembly files are different, then you want to start
diffing the dump files.  The dumps happen in the following order:

	.rtl
	.jump
	.cse
	.addressof
	.gcse
	.loop
	.cse2
	.bp
	.flow
	.combine
	.regmove
	.sched
	.lreg
	.greg
	.flow2
	.sched2
	.jump2
	.mach
	.dbr


You want to find the first one that is different, which will give us a good 
idea
of what part of the compiler is messing up.

jeff