* ICE building glibc-2.2.5 using m68k-linux gcc-3.1
@ 2002-07-22 17:22 Peter Barada
2002-07-25 13:32 ` Richard Zidlicky
0 siblings, 1 reply; 6+ messages in thread
From: Peter Barada @ 2002-07-22 17:22 UTC (permalink / raw)
To: gcc; +Cc: 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)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1
2002-07-22 17:22 ICE building glibc-2.2.5 using m68k-linux gcc-3.1 Peter Barada
@ 2002-07-25 13:32 ` Richard Zidlicky
2002-07-25 15:45 ` Peter Barada
0 siblings, 1 reply; 6+ messages in thread
From: Richard Zidlicky @ 2002-07-25 13:32 UTC (permalink / raw)
To: Peter Barada; +Cc: gcc
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++))]();
}
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1
2002-07-25 13:32 ` Richard Zidlicky
@ 2002-07-25 15:45 ` Peter Barada
2002-07-26 8:50 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Peter Barada @ 2002-07-25 15:45 UTC (permalink / raw)
To: Richard.Zidlicky; +Cc: Peter.Barada, gcc
>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)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1
2002-07-25 15:45 ` Peter Barada
@ 2002-07-26 8:50 ` Richard Henderson
2002-07-26 15:52 ` Richard Zidlicky
2002-07-27 15:18 ` Richard Zidlicky
0 siblings, 2 replies; 6+ messages in thread
From: Richard Henderson @ 2002-07-26 8:50 UTC (permalink / raw)
To: Peter Barada; +Cc: Richard.Zidlicky, Peter.Barada, gcc
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~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1
2002-07-26 8:50 ` Richard Henderson
@ 2002-07-26 15:52 ` Richard Zidlicky
2002-07-27 15:18 ` Richard Zidlicky
1 sibling, 0 replies; 6+ messages in thread
From: Richard Zidlicky @ 2002-07-26 15:52 UTC (permalink / raw)
To: Richard Henderson; +Cc: Peter.Barada, gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1
2002-07-26 8:50 ` Richard Henderson
2002-07-26 15:52 ` Richard Zidlicky
@ 2002-07-27 15:18 ` Richard Zidlicky
1 sibling, 0 replies; 6+ messages in thread
From: Richard Zidlicky @ 2002-07-27 15:18 UTC (permalink / raw)
To: Richard Henderson; +Cc: Peter.Barada, gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-07-27 10:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-22 17:22 ICE building glibc-2.2.5 using m68k-linux gcc-3.1 Peter Barada
2002-07-25 13:32 ` Richard Zidlicky
2002-07-25 15:45 ` Peter Barada
2002-07-26 8:50 ` Richard Henderson
2002-07-26 15:52 ` Richard Zidlicky
2002-07-27 15:18 ` Richard Zidlicky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).