GCC 3.1 bug? - looks like it miscompiles optimize_mode_switching()

[tm <tm at mail dot kloo dot net>]

host: i386-linux (RH 7.1)

When I configure CVS head for --target=sh-elf and compile it with GCC 3.1,
the build aborts with a segfault.

The summary is: it seems GCC 3.1 miscompiles optimize_mode_switching.

The crash looks like this;

(gdb) set args -isystem /usr/local/sh-elf/include -O2  -DIN_GCC
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/config -I../../gcc/gcc/../include
-m4-single -DL_negdi2 ../../gcc/gcc/libgcc2.c -o
libgcc/m4-single/_negdi2.o
(gdb) run
Starting program: /home/tm/gcc-build-sh-elf/gcc/cc1 -isystem
/usr/local/sh-elf/include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem
./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc
-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/config
-I../../gcc/gcc/../include  -m4-single -DL_negdi2 ../../gcc/gcc/libgcc2.c
-o libgcc/m4-single/_negdi2.o
 __negdi2
Program received signal SIGSEGV, Segmentation fault.
0x082b059a in optimize_mode_switching (file=0x0) at
../../gcc/gcc/lcm.c:1166
1166		    info[bb->index].seginfo->mode = mode;
(gdb) print bb->index
$1 = 0
(gdb) print info[0]
Cannot access memory at address 0x2
(gdb) print info
$2 = (Elf32_Dyn **) 0x2
(gdb) print bb_info[j]
$4 = (struct bb_info *) 0x8468b78

My analysis of this dump is as follows:

At lcm.c line 1081, the variable "info" is set:

      struct bb_info *info = bb_info[j];

then at line 1123, info is referenced:

          info[bb->index].computing = last_mode;

The problem is "info" now contains the value 2 instead of 0x8468b78 so
the code crashes.

Disassembling lcm.o reveals:

      int no_mode = num_modes[e];
      struct bb_info *info = bb_info[j];
    15f4:       8b 54 15 a4             mov
0xffffffa4(%ebp,%edx,1),%edx
    15f8:       8b 04 85 00 00 00 00    mov    0x0(,%eax,4),%eax
    15ff:       89 95 70 ff ff ff       mov    %edx,0xffffff70(%ebp)
    1605:       89 85 74 ff ff ff       mov    %eax,0xffffff74(%ebp)

                                                    ^ info allocated at
                                                      0xffffff74(%ebp)
...
          info[bb->index].computing = last_mode;
    16e2:       8b 55 98                mov    0xffffff98(%ebp),%edx
    16e5:       8b b5 6c ff ff ff       mov    0xffffff6c(%ebp),%esi
    16eb:       8b 8d 70 ff ff ff       mov    0xffffff70(%ebp),%ecx

                                               ^ info referenced at 
                                                 0xffffff70(%ebp)
                                                 looks wrong!

    16f1:       8b 42 2c                mov    0x2c(%edx),%eax
    16f4:       89 74 c1 04             mov    %esi,0x4(%ecx,%eax,8)

It appears info is stored in one stack slot and retrieved from a different
stack slot which causes a wrong value to be used for the subsequent
dereference.

Toshi