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

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

[Peter Barada]

Follwing Bill Gatliff's instructiosn for building a cross compiler,
I build binutils-2.12.1 for m68k-linux, a bootstrap gcc-3.1 m68k cross
compiler configured with '--target=m68k-linux --prefix=/tmp/crap
--enable-languages=c --with-local-prefix=/tmp/crap/m68k-linux
--without-headers --with-newlib --disable-shared --verbose', and that
succeeded.

Next step is building glibc-2.2.5 configured with
'CC=m68k-linux-cc AR=m68k-linux-ar RANLIB=m68k-linux-ranlib
$path-to-configure/configure  --host=m68k-linux
--prefix=/tmp/crap/m68k-linux --enale-add-ons=linuxthreads
--with-headers=/tmp/crap/m68k-linux/include'

It blows up in iconvdata bulding euc-kr.c:

make[2]: Entering directory `/home/pbarada/work/cvs-wavemark/cross-linux-tools/glibc-2.2.5/iconvdata'
m68k-linux-gcc euc-kr.c -c -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g   -fpic    -I../include -I. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/crap/m68k-linux/glibc/iconvdata -I.. -I../libio  -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/crap/m68k-linux/glibc -I../sysdeps/m68k/elf -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/m68k -I../sysdeps/unix/sysv/linux/m68k -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/m68k/m68020 -I../sysdeps/m68k/fpu -I../sysdeps/m68k -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem /tmp/!
!
!
crap/lib/gcc-lib/m68k-linux/3.1/include -isystem /tmp/crap/m68k-linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED   -o /home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/crap/m68k-linux/glibc/iconvdata/euc-kr.os
../wcsmbs/wchar.h: In function `from_euc_kr':
../wcsmbs/wchar.h:520: Internal compiler error in simplify_unary_operation, at simplify-rtx.c:532
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/crap/m68k-linux/glibc/iconvdata/euc-kr.os] Error 1
make[2]: Leaving directory `/home/pbarada/work/cvs-wavemark/cross-linux-tools/glibc-2.2.5/iconvdata'


I pulled up gdb on it, and the (relavent parts of the) traceback is:

(gdb) where
#0  fancy_abort (
    file=0x81fcbc0 "/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/simplify-rtx.c", line=532, 
    function=0x81fccf8 "simplify_unary_operation")
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/diagnostic.c:1452
#1  0x0813d97d in simplify_unary_operation (code=ZERO_EXTEND, mode=SImode, 
    op=0x4021b908, op_mode=VOIDmode)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/simplify-rtx.c:532
#2  0x0813d2e5 in simplify_gen_unary (code=ZERO_EXTEND, mode=SImode, 
    op=0x4021b908, op_mode=VOIDmode)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/simplify-rtx.c:202
#3  0x0813d497 in simplify_replace_rtx (x=0x4021b968, old=0x40276980, 
    new=0x4021b908)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/simplify-rtx.c:276
#4  0x08196607 in try_replace_reg (from=0x40276980, to=0x4021b908, 
    insn=0x40278520)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/gcse.c:3987
#5  0x08196990 in cprop_insn (bb=0x82e384c, insn=0x40278520, alter_jumps=0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/gcse.c:4210

At frame 5, the call to try_replace_reg has an insn of:

(gdb) fra 5
#5  0x08196990 in cprop_insn (bb=0x82e384c, insn=0x40278520, alter_jumps=0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-stock-3.1/gcc/gcse.c:4210
(gdb) call debug_rtx(insn)

(insn 165 164 168 (set (strict_low_part (subreg:QI (reg:SI 64) 3))
        (const_int -128 [0xffffff80])) 38 {*m68k.md:1072} (nil)
    (expr_list:REG_EQUAL (zero_extend:SI (const_int -128 [0xffffff80]))
        (nil)))

The call to simplify_unary_operation blows up because op_mode is
VOIDmode and the zero_extend code need to know the mode of the
const_int (simplify-rtx.c:533): 

	case ZERO_EXTEND:
	  /* When zero-extending a CONST_INT, we need to know its
             original mode.  */
	  if (op_mode == VOIDmode)
	    abort ();

From euc-kr.c.03.jump I see:

(insn 141 140 142 (set (reg/v:QI 54)
        (const_int -128 [0xffffff80])) -1 (nil)
    (nil))

...

(insn 165 164 166 (set (strict_low_part (subreg:QI (reg:SI 64) 3))
        (reg/v:QI 54)) -1 (nil)
    (expr_list:REG_EQUAL (zero_extend:SI (reg/v:QI 54))
        (nil)))

And from euc-kr.c.08.cse I see:

(insn 165 164 168 (set (strict_low_part (subreg:QI (reg:SI 64) 3))
        (reg/v:QI 54)) 38 {*m68k.md:1072} (nil)
    (expr_list:REG_EQUAL (zero_extend:SI (const_int -128 [0xffffff80]))
        (nil)))

So it looks like the constant propagation was done, but the mode of
the original const_int was lost.  I would have expected to see:

(insn 165 164 168 (set (strict_low_part (subreg:QI (reg:SI 64) 3))
        (reg/v:QI 54)) 38 {*m68k.md:1072} (nil)
    (expr_list:REG_EQUAL (zero_extend:SI (const_int:QI -128 [0xffffff80]))
        (nil)))

Where is the constant proagation done(exactly)?  I'm thinking of
trying an experiment where the mode of the int is set to the width of
the target for constant assignments to see if that makes this go
away.  Of course I may be completely off base here...

I'm currently grabbing the latest snapshot to see if this problem is
current. 

Any and all suggestions on how to proceed in getting past this are much
appreciated!

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

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

[Richard Zidlicky]

On Mon, Jul 22, 2002 at 04:09:59PM -0400, Peter Barada wrote:
> 
':
> ../wcsmbs/wchar.h:520: Internal compiler error in simplify_unary_operation, at simplify-rtx.c:532
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

not much help I am afraid, but I have had a few similar problems 
with native m68k-linux on 3.1. I managed to reduce one testcase 
to something really small, perhaps you can see something from it.

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++))]();
}

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

[Peter Barada]

>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)

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

[Richard Henderson]

On Thu, Jul 25, 2002 at 03:33:20PM -0400, Peter Barada wrote:
> (gdb) call debug_rtx(set)
> 
> (set (strict_low_part (reg:HI 6 %d6))
>     (reg:HI 30))

This is wrong.  The argument to STRICT_LOW_PART must always be
a SUBREG of a REG.


r~

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

[Richard Zidlicky]

On Thu, Jul 25, 2002 at 06:04:31PM -0700, Richard Henderson wrote:
> On Thu, Jul 25, 2002 at 03:33:20PM -0400, Peter Barada wrote:
> > (gdb) call debug_rtx(set)
> > 
> > (set (strict_low_part (reg:HI 6 %d6))
> >     (reg:HI 30))
> 
> This is wrong.  The argument to STRICT_LOW_PART must always be
> a SUBREG of a REG.

so the responsible pattern seems to be

(define_expand "zero_extendhisi2"
  [(set (match_operand:SI 0 "register_operand" "")
	(const_int 0))
   (set (strict_low_part (match_dup 2))
	(match_operand:HI 1 "general_operand" ""))]
  ""
  "
{
  operands[1] = make_safe_from (operands[1], operands[0]);
  operands[2] = gen_lowpart (HImode, operands[0]);
}")

Funny enough, the m68k version of zero_extendhisi2 insn pattern 
is part of the gcc internals docs for 3.x and it is written
differently there, with an (subreg:HI ...) so I am trying this
variant now - anyone remembers when or why it was changed?

Richard

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

[Richard Zidlicky]

On Thu, Jul 25, 2002 at 06:04:31PM -0700, Richard Henderson wrote:
> On Thu, Jul 25, 2002 at 03:33:20PM -0400, Peter Barada wrote:
> > (gdb) call debug_rtx(set)
> > 
> > (set (strict_low_part (reg:HI 6 %d6))
> >     (reg:HI 30))
> 
> This is wrong.  The argument to STRICT_LOW_PART must always be
> a SUBREG of a REG.

I have tracked it down to following kludge which makes gen_lowpart
return a REG instead of SUBREG ins some cases:

simplify-rtx.c:simplify_subreg:2644
      int final_regno = subreg_hard_regno (gen_rtx_SUBREG (outermode, op, byte),
					   0);

      /* ??? We do allow it if the current REG is not valid for
	 its mode.  This is a kludge to work around how float/complex
	 arguments are passed on 32-bit Sparc and should be fixed.  */
      if (HARD_REGNO_MODE_OK (final_regno, outermode)
	  || ! HARD_REGNO_MODE_OK (REGNO (op), innermode))
	{
	  rtx x = gen_rtx_REG (outermode, final_regno);

	  /* Propagate original regno.  We don't have any way to specify
	     the offset inside orignal regno, so do so only for lowpart.
	     The information is used only by alias analysis that can not
	     grog partial register anyway.  */

	  if (subreg_lowpart_offset (outermode, innermode) == byte)
	    ORIGINAL_REGNO (x) = ORIGINAL_REGNO (op);
	  return x;
	}

This returns REG instead of SUBREG, is this special case still needed?

The backtrace at this point is:
#0  simplify_subreg (outermode=HImode, op=0x400dbd10, innermode=SImode, byte=2)
    at ../../gcc-3.1/gcc/simplify-rtx.c:2653
#1  0x81597c2 in simplify_gen_subreg (outermode=HImode, op=0x400dbd10, 
    innermode=SImode, byte=2) at ../../gcc-3.1/gcc/simplify-rtx.c:2724
#2  0x80b2977 in gen_lowpart_common (mode=HImode, x=0x400dbd10)
    at ../../gcc-3.1/gcc/emit-rtl.c:857
#3  0x80b2cf2 in gen_lowpart (mode=HImode, x=0x400dbd10)
    at ../../gcc-3.1/gcc/emit-rtl.c:1153
#4  0x80f9dc3 in gen_zero_extendhisi2 (operand0=0x400dbd10, 
    operand1=0x400dbdc0) at insn-emit.c:2952
#5  0x8118e4a in emit_unop_insn (icode=454, target=0x400dbd10, op0=0x400dbdc0, 
    code=ZERO_EXTEND) at ../../gcc-3.1/gcc/optabs.c:2682




Richard