Example of debugging GCC with toplevel bootstrap

[Paolo Bonzini]

Hello,

this is a real log of debugging GCC (with stage1 C miscompiling stage2 
Fortran), including finding the miscompilation and fixing it.  I hope it 
helps understanding the way toplevel bootstrap works.

    ../configure

I just need two stages because I know that stage1 C miscompiles stage2 
Fortran.  I use all-stage2, rather than bootstrap2, to avoid building 
target libraries.  This is like doing "make -C gcc bootstrap2" in the 
old scheme.

    make all-stage2 STAGE1_LANGUAGES=c,fortran

I use the stage1 compiler to make the target libraries, to avoid that 
the miscompilation hits in libgfortran.

    make stage1-start
    make all-target-libgfortran

Unfortunately, all target directories are staged, even non-bootstrapped 
ones, because of multilibbing.  So I copy everything in the stage1 
target directory to the stage2 target directory.  But this annoyance is 
actually good because in the future it will allow me to use the same 
libgcc for both executables.  This shields from potential 
miscompilations of the stage2 C front-end (we have a buggy stage1 
compiler!).

    make stage      # This is just for simplicity
    cp -R stage1-powerpc*/* stage2-powerpc*/

Run stage2's regression tests (in this case I could have found the 
failing testcase from the PR, but I was disconnected from Internet):

    make stage2-start ; make -C gcc check-fortran

As soon as a test fails, make sure it did not fail in stage1.

    make stage1-start ; make -C gcc check-fortran 
RUNTESTFLAGS=dg.exp=complex_intrinsic_1.f90

Find out the command line to f951 (in reality, I cut & pasted from the 
dejagnu log file and just added -### to the end).

    gcc/gfortran -Bgcc 
../gcc//testsuite/gfortran.dg/complex_intrinsic_1.f90 -S -###

Ok, we are ready to debug.  In this case, I prefer to have two distinct 
debuggers, and having directories
names stage1-gcc and stage2-gcc actually helps me.  Hence the first make 
invocation.

    make stage
    cp ../gcc/testsuite/gfortran.dg/complex_intrinsic_1.f90 aaa.f90
    stage1-gcc/f951 aaa.f90 -fPIC -o stage1.s
    stage2-gcc/f951 aaa.f90 -fPIC -o stage2.s
    diff stage1.s stage2.s

This was just to be sure that I identified a failure mode.  After 
reducing the testcase a bit, I set to find the front-end miscompilation.

    gdb --args stage1-gcc/f951 aaa.f90 -o stage1.s
    gdb --args stage2-gcc/f951 aaa.f90 -o stage2.s

... some time later a.c contains the reduced testcase for the Fortran 
front-end miscompilation, and I don't need anymore to work with two 
stages at a time.  Working in a gcc directory now will be like working 
in a non-bootstrapped build.

    make stage1-start
    cd gcc
    gdb --args ./cc1 -O2 -o - ../a.c

... fix bug in combine.c ...

    make cc1
    ./cc1 -O2 -o - ../a.c

... seems fixed ...

    ./xgcc -B. -O2 -o test ../a.c
    ./test

Ok, looks like I'm done.  Since stage1 miscompiled stage2, I expect many 
if not all object files to change, and I cannot do a bubblestrap.  There 
is no equivalent of `make restrap', so I manually delete stage2.

    cd ..
    rm -rf stage2-* stage1-powerpc*
    make bootstrap
    make -k check

(It occurs now to me that restrap is easy to implement, so I will submit 
a patch as soon as the queue is exhausted).  A few hours later... yay, 
bug fixed!

Paolo