From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12638 invoked by alias); 25 Jul 2002 19:33:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12614 invoked from network); 25 Jul 2002 19:33:25 -0000 Received: from unknown (HELO motgate4.mot.com) (144.189.100.102) by sources.redhat.com with SMTP; 25 Jul 2002 19:33:25 -0000 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA03756; Thu, 25 Jul 2002 12:33:25 -0700 (MST)] Received: [from mail.wm.sps.mot.com ([199.10.246.2]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA05768; Thu, 25 Jul 2002 12:33:24 -0700 (MST)] Received: from hyper.wm.sps.mot.com (hyper.wm.sps.mot.com [199.10.246.43]) by mail.wm.sps.mot.com (8.9.3/8.9.3) with ESMTP id PAA07049; Thu, 25 Jul 2002 15:33:16 -0400 Received: by hyper.wm.sps.mot.com (8.11.2) id g6PJXKp06132; Thu, 25 Jul 2002 15:33:20 -0400 Date: Thu, 25 Jul 2002 15:45:00 -0000 Message-Id: <200207251933.g6PJXKp06132@hyper.wm.sps.mot.com> From: Peter Barada To: Richard.Zidlicky@stud.informatik.uni-erlangen.de CC: Peter.Barada@motorola.com, gcc@gcc.gnu.org In-reply-to: <20020725172702.B1938@linux-m68k.org> (message from Richard Zidlicky on Thu, 25 Jul 2002 17:27:02 +0200) Subject: Re: ICE building glibc-2.2.5 using m68k-linux gcc-3.1 References: <200207222009.g6MK9xI27711@hyper.wm.sps.mot.com> <20020725172702.B1938@linux-m68k.org> X-SW-Source: 2002-07/txt/msg01243.txt.bz2 >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 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)