From: Peter Barada <pbarada@mail.wm.sps.mot.com>
To: gcc@gcc.gnu.org
Cc: Peter.Barada@Motorola.com
Subject: ICE building glibc-2.2.5 using m68k-linux gcc-3.1
Date: Mon, 22 Jul 2002 17:22:00 -0000 [thread overview]
Message-ID: <200207222009.g6MK9xI27711@hyper.wm.sps.mot.com> (raw)
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)
next reply other threads:[~2002-07-22 20:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-22 17:22 Peter Barada [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200207222009.g6MK9xI27711@hyper.wm.sps.mot.com \
--to=pbarada@mail.wm.sps.mot.com \
--cc=Peter.Barada@Motorola.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).