Bug 14576 - [3.4/3.5? Regression] ICE in libiberty when building gcc-3.4 for arm-elf
Summary: [3.4/3.5? Regression] ICE in libiberty when building gcc-3.4 for arm-elf
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.4.1
Assignee: Not yet assigned to anyone
Keywords: ice-on-valid-code
Depends on:
Reported: 2004-03-15 09:52 UTC by Rob Brown
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-linux-pc-gnu
Target: arm-elf
Known to work:
Known to fail:
Last reconfirmed:

preprocessed source for d_print_comp() (3.17 KB, text/plain)
2004-03-15 09:54 UTC, Rob Brown

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Brown 2004-03-15 09:52:38 UTC
Please forgive me if this is a dup of 14166, 14302, 14558, or anything else. I 
don't think it is... 
When building a cross-compiler with gcc-3.4 snapshots (I only have 20040303 
and 20040310), there is an ICE when compiling at -O3. The ICE does not occur 
at -O2, nor does it happen in gcc-3.3.3 release. 
I have a symlink to the newlib (1.12.0) directory in the gcc source base 
directory. "build" directory is also in the gcc source base directory. Build 
compiler is gcc-3.3.3. 
Command line is: 
CFLAGS="-O3 -pipe" ../configure --prefix=/usr --target=arm-elf 
--enable-languages=c,c++ --with-newlib --disable-multilib --with-gnu-ld 
--with-gnu-as && make 
Relevant output is: 
-B/home/rfbrown/build/gcc-3.4-20040310/build/gcc/ -nostdinc 
-isystem /home/rfbrown/build/gcc-3.4-20040310/build/arm-elf/newlib/targ-include 
-isystem /home/rfbrown/build/gcc-3.4-20040310/newlib/libc/include 
-B/usr/arm-elf/bin/ -B/usr/arm-elf/lib/ -isystem /usr/arm-elf/include 
-isystem /usr/arm-elf/sys-include -c -DHAVE_CONFIG_H -O2 -O3 -pipe -I. 
-I../../../libiberty/../include  -W -Wall -Wtraditional 
-pedantic ../../../libiberty/cp-demangle.c -o cp-demangle.o 
../../../libiberty/cp-demangle.c: In function `d_print_comp': 
../../../libiberty/cp-demangle.c:3438: error: insn does not satisfy its 
(insn:HI 4207 13052 13051 279 ../../../libiberty/cp-demangle.c:3191 (set 
(mem/s:SI (post_modify:SI (reg:SI 1 r1) 
                (plus:SI (reg:SI 1 r1) 
                    (const_int 16 [0x10]))) [55 <variable>.next+0 S4 A32]) 
        (reg:SI 2 r2)) 125 {*arm_movsi_insn} (insn_list:REG_DEP_ANTI 4160 
(insn_list:REG_DEP_ANTI 4155 (insn_list:REG_DEP_OUTPUT 4199 
(insn_list:REG_DEP_ANTI 4198 (nil))))) 
    (expr_list:REG_DEAD (reg:SI 2 r2) 
        (expr_list:REG_INC (reg:SI 1 r1) 
../../../libiberty/cp-demangle.c:3438: internal compiler error: in 
copyprop_hardreg_forward_1, at regrename.c:1549 
Please submit a full bug report, 
with preprocessed source if appropriate. 
Attachment is preprocessed source for just the d_print_comp function, let me 
know if you want the whole file. 
linux binutils here is (from sources.redhat.com). arm-elf binutils 
is 2.14 (vanilla gnu).
Comment 1 Rob Brown 2004-03-15 09:54:21 UTC
Created attachment 5916 [details]
preprocessed source for d_print_comp()
Comment 2 Andrew Pinski 2004-03-15 14:14:12 UTC
I think this is a regression from 3.3.2.
Comment 3 Rob Brown 2004-03-29 08:16:32 UTC
(In reply to comment #2)
> I think this is a regression from 3.3.2.

Hmmm, it doesn't happen in 3.3.3, but I guess that doesn't mean anything much.
I'll bow to your superior knowledge!

I see this is targetted for 3.4.1, which is fine, so I won't spam this bug but
I'll just mention that it is still present in the gcc-3.4-20040324 snapshot.
Comment 4 Dara Hazeghi 2004-05-12 23:00:08 UTC
Umm... The source attached here isn't preprocessed. Could you please attach the .i file generated when 
you compile with -save-temps? Thanks.
Comment 5 Rob Brown 2004-05-13 21:57:25 UTC
Well, this is just typical: just tried it with gcc-3.4-20040502 and the problem 
is gone! I've tried it with several tweaks to the build switches, and can't get 
it to fail with any of them.

Ah well, a good result nonetheless. Would you still like the preprocessed 
Comment 6 Dara Hazeghi 2004-05-14 04:07:01 UTC
Not at this point, thanks. Next time (hopefully there won't be one) it'd be good though, since we like to 
add testcases to the testsuite so things that are fixed aren't accidentally broken again.

Glad that things are fixed in any case!