Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1

[Peter Barada <pbarada@mail.wm.sps.mot.com>]

>Btw it does no longer cause an ICE for 3.1.1 but the program from
>which it is taken still doesn't work correctly.
>
>Richard
>
>#### compile with -O0 to trigger ICE ####
>
>extern void (**table)(void);
>
>typedef unsigned short uw16;
>typedef unsigned int gshort;
>
>register uw16 *pc asm("%a4");
>register gshort code asm("%d6");
>
>
>void QMExecuteLoop(uw16 *oldPC)
>{
>            table[code=(*(uw16*)(pc++))]();
>}

This *does* cause an ICE on gcc 3.1.1 20020722 (prerelease):

[pbarada: /tmp] > /tmp/20020722/bin/m68k-linux-gcc -O0 -o /tmp/yy.s -S /tmp/yy.c
/tmp/yy.c: In function `QMExecuteLoop':
/tmp/yy.c:12: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
[pbarada: /tmp] > /tmp/20020722/bin/m68k-linux-gcc -v
Reading specs from /tmp/20020722/lib/gcc-lib/m68k-linux/3.1.1/specs
Configured with: /home/pbarada/work/cvs-wavemark/cross-tools/gcc-20020722/configure --target=m68k-linux --prefix=/tmp/20020722 --enable-languages=c,c++ --with-local-prefix=/tmp/20020722/m68k-linux
Thread model: single
gcc version 3.1.1 20020722 (prerelease)

It blows up in rtx_equal_p with the follwing stack trace:

(gdb) where
#0  rtx_equal_p (x=0x6, y=0x4017bd10)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-20020722/gcc/rtl.c:510
#1  0x08105788 in add_equal_note (seq=0x4017f9c8, target=0x4017bd10, 
    code=ZERO_EXTEND, op0=0x4017bdc0, op1=0x0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-20020722/gcc/optabs.c:143
#2  0x0810954c in emit_unop_insn (icode=454, target=0x4017bd10, 
    op0=0x4017bdc0, code=ZERO_EXTEND)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-20020722/gcc/optabs.c:2685
#3  0x080ba8ad in convert_move (to=0x4017bd10, from=0x4017bdc0, unsignedp=1)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-20020722/gcc/expr.c:1060

Note that 'x' is 0x6 in this case and in add_equal_note, 'set' is:

(gdb) call debug_rtx(set)

(set (strict_low_part (reg:HI 6 %d6))
    (reg:HI 30))

(gdb) p set->fld[0].rtx.code
$1 = STRICT_LOW_PART

And at optabs.c:151, the expression:
	  && (GET_CODE (SET_DEST (set)) != STRICT_LOW_PART
	      || ! rtx_equal_p (SUBREG_REG (XEXP (SET_DEST (set), 0)),
				target))))

Is failing since GET_CODE (SET_DEST (set)) == STRICT_LOW_PART, and
SUBREG_REG (XEXP (SET_DEST (set), 0)) is 0x6.  The expression
SUBREG_REG (XEXP (SET_DEST (set), 0)) expands (via cpp) into:

 (((((((((set)->fld[0]).rtx))->fld[0]).rtx))->fld[0]).rtx)

From gdb:

(gdb) call debug_rtx(set)

(set (strict_low_part (reg:HI 6 %d6))
    (reg:HI 30))
(gdb) p set->fld[0].rtx
$16 = 0x4017f9c0
(gdb) p set->fld[0].rtx->fld[0].rtx
$17 = 0x4017be00
(gdb) p set->fld[0].rtx->fld[0].rtx->fld[0].rtx
$18 = 0x6
(gdb) call debug_rtx(set->fld[0].rtx)

(strict_low_part (reg:HI 6 %d6))
(gdb) 

Perhaps the code should be:

	  && (GET_CODE (SET_DEST (set)) != STRICT_LOW_PART
	      || ! rtx_equal_p (SUBREG_REG (SET_DEST (set), 0),
				target))))

which expands into set->fld[0].rtx->fld[0].rtx
And in gdb evauates to:

(gdb) p set->fld[0].rtx->fld[0].rtx
$20 = 0x4017be00
(gdb) call debug_rtx($19)

(reg:HI 6 %d6)

Any ideas???

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)