Re: ICE building on darwin

[Geoff Keating <geoffk at geoffk dot org>]

Syd Polk <spolk@apple.com> writes:

> On Feb 3, 2004, at 1:54 PM, Mike Stump wrote:
> >
> > Try:
> >
> > 	make clean && make bootstrap
> >
> > and see if that cures it.  Brownie points if you save off the *.o
> > files, and find the one that is missing the dependency in the
> > makefile.
> >
> >
> 
> I'm sorry; I reported the wrong ICE. This is from clean:
> 
> stage1/xgcc -Bstage1/
> -B/Users/jazzman/Work/Compiler/build/iPod/gcc.gnu.org/TOT/powerpc-
> apple-darwin/../../../../../install/iPod/gcc.gnu.org/TOT/powerpc-apple-
> darwin/powerpc-apple-darwin7.2.0/bin/ -c   -g -O2 -DIN_GCC   -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
> -Wno-long-long -Wold-style-definition -Werror -fno-common
> -DHAVE_CONFIG_H    -I. -I.
> -I/Volumes/Syd/Work/Compiler/gcc.gnu.org/TOT/gcc/gcc
> -I/Volumes/Syd/Work/Compiler/gcc.gnu.org/TOT/gcc/gcc/.
> -I/Volumes/Syd/Work/Compiler/gcc.gnu.org/TOT/gcc/gcc/../include
> -I../intl /Volumes/Syd/Work/Compiler/gcc.gnu.org/TOT/gcc/gcc/reload.c
> -o reload.o
> [address=0077a35b pc=0053bb1c]
> /Volumes/Syd/Work/Compiler/gcc.gnu.org/TOT/gcc/gcc/reload.c: In
> function `find_reloads':
> /Volumes/Syd/Work/Compiler/gcc.gnu.org/TOT/gcc/gcc/reload.c:4382:
> 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.
> make[1]: *** [reload.o] Error 1
> make: *** [stage2_build] Error 2

It turns out that this is all the information you need to find the
patch that introduced the problem, which is good since this doesn't
happen to me if I run the command by hand, and when I used -dH and
tried to get a backtrace, the backtrace stopped at the signal handler.
I got:

[address=0077135b pc=0053b4b8]

That address corresponds to:

(gdb) list *0x53b4b8
0x53b4b8 is in find_equiv_reg (/Volumes/Data/build/gcc-1/a~dir/gcc-1/gcc/gcc/reload.c:6590).
6585                                           goal, (rtx*) 0))
6586        return 0;
6587
6588      /* Reject registers that overlap GOAL.  */
6589
6590      if (!goal_mem && !goal_const
6591          && regno + (int) hard_regno_nregs[regno][mode] > valueno
6592          && regno < valueno + (int) hard_regno_nregs[valueno][mode])
6593        return 0;
6594

Now, gdb isn't being very specific about *which* line corresponds to
53b4b8, but surely the problem is that the array access is
out-of-bounds, so that means it's the patch that introduced the array.

After much debugging (including some help from the corefile produced
with -dH), I found that this is because GOAL is actually a REG of a
pseudo-register, which seems perfectly allowable as an input to this
function.  A patch will follow shortly.

-- 
- Geoffrey Keating <geoffk@geoffk.org>