This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
We get the following ICE when crosscompiling fbtest from i686-pc-linux-gnu to arm-ep93xx-linux-gnueabi. -O3 breaks, -O2 works [mkl@himalia:~/pengutronix/ptxdist/bug]$ arm-ep93xx-linux-gnueabi-gcc -c -Wall -O3 -fomit-frame-pointer -o minimal.o minimal.c -save-temps -v Using built-in specs. Target: arm-ep93xx-linux-gnueabi Configured with: /home/mkl/pengutronix/ptxdist/build/toolchain-arm-ep93xx-linux-gnueabi/build-cross/gcc-4.1.1/configure --host=i686-host-linux-gnu --target=arm-ep93xx-linux-gnueabi --prefix=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4 --with-local-prefix=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi --with-sysroot=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi --disable-multilib --disable-nls --enable-symvers=gnu --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-shared --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 4.1.1 /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/libexec/gcc/arm-ep93xx-linux-gnueabi/4.1.1/cc1 -E -quiet -v minimal.c -Wall -fomit-frame-pointer -O3 -fpch-preprocess -o minimal.i ignoring nonexistent directory "/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/include" #include "..." search starts here: #include <...> search starts here: /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/lib/gcc/arm-ep93xx-linux-gnueabi/4.1.1/include /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/lib/gcc/arm-ep93xx-linux-gnueabi/4.1.1/../../../../arm-ep93xx-linux-gnueabi/include /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/usr/include End of search list. /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/libexec/gcc/arm-ep93xx-linux-gnueabi/4.1.1/cc1 -fpreprocessed minimal.i -quiet -dumpbase minimal.c -auxbase-strip minimal.o -O3 -Wall -version -fomit-frame-pointer -o minimal.s GNU C version 4.1.1 (arm-ep93xx-linux-gnueabi) compiled by GNU C version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 770ce336670905d74fe72d7a025d3915 minimal.c: In function 'main': minimal.c:49: error: unrecognizable insn: (insn 284 119 282 13 (set (reg:HI 14 lr) (mem/s:HI (plus:SI (mult:SI (reg/v:SI 1 r1 [orig:122 i ] [122]) (const_int 16 [0x10])) (reg:SI 6 r6 [orig:114 clut.1 ] [114])) [3 <variable>.r+0 S4 A32])) -1 (nil) (nil)) minimal.c:49: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created an attachment (id=12056) [edit] small testcase to trigger the bug
-O3 works here while -O2 fails - but, in any case, confirmed.
I was on gcc 4.2 btw.
A regression hunt using an arm-ep93xx-linux-gnueabi cross compiler on powerpc-linux, with the testcase minimal.c, identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=105121 r105121 | kazu | 2005-10-08 18:17:20 +0000 (Sat, 08 Oct 2005) This is a large merge from the csl-arm-branch to mainline. The test does not fail for a cross compiler built from revision 104998, the last revision on that branch before the merge, suggesting that his is a problem with the merge itself.
This is looking like a latent reload bug. I don't see anything in r105121 that could cause this bug. I can reproduce it on non-linux and non-eabi arm targets.
I am getting exactly the same here on ppc (so it is not just arm specific): $ c++ -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
Subject: Re: [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm] On Wed, 2006-09-20 at 16:38 +0000, bugreports at nn7 dot de wrote: > > ------- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 ------- > I am getting exactly the same here on ppc (so it is not just arm specific): Yes it is. The bug you are getting with PPC is a different bug and should be filed separately. Thanks, Andrew Pinski
gcc/testsuite/gcc.dg/compat/scalar-return-4_y.c fails with this ICE. Do you know if this is the same or a different problem? This is on ARM old ABI, fails with 4.1 and 4.2. 4.0 works.
../../src/gcc/testsuite/gcc.dg/compat/scalar-return-4_y.c:41: error: unrecognizable insn: (insn 39 20 21 3 (set (reg:HI 0 r0) (subreg:HI (mem/c:CQI (plus:SI (reg/f:SI 11 fp) (const_int -16 [0xfffffff0])) [0 S2 A8]) 0)) -1 (nil) (nil)) ../../src/gcc/testsuite/gcc.dg/compat/scalar-return-4_y.c:41: internal compiler error: in extract_insn, at recog.c:2077
And gcc.c-torture/execute/20050121-1.c (sid)tbm@ALL6500:~/build/gcc-snapshot-20060922/build/gcc$ ./xgcc -B. -o x -c ../../src/gcc/testsuite/gcc.c-torture/execute/20050121-1.c ../../src/gcc/testsuite/gcc.c-torture/execute/20050121-1.c: In function 'foo_char': ../../src/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33: error: unrecognizable insn: (insn 55 36 37 2 (set (reg:HI 0 r0) (subreg:HI (mem/c:CQI (plus:SI (reg/f:SI 11 fp) (const_int -24 [0xffffffe8])) [0 S2 A8]) 0)) -1 (nil) (nil)) ../../src/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33: internal compiler error: in extract_insn, at recog.c:2077
I ICE in comment #10 looks like it may be a different problem.
Before reload the problematic instruction is: (set (mem:HI (something)) (subreg:HI (reg:SI 177))) Reload decides to reload the second operand into a register. In find_reloads_subreg_address, reg_equiv_memory_loc tells us that reg 117 is equivalent to (mem:SI (plus:SI (mult:SI (reg:SI r1) (const_int 16)) (reg:SI r6))) This is a valid SImode address, but not a valid HImode address. we change the mem:SI to mem:HI, then call find_reloads_address to fixup the result. However the comment above find_reloads_address says: Note that there is no verification that the address will be valid after this routine does its work. Instead, we rely on the fact that the address was valid when reload started. So we need only undo things that reload could have broken. These are wrong register types, pseudos not allocated to a hard register, and frame pointer elimination. */ No mention of having broken the address by changing the mode of the mem. The new HImode mem passes through find_reloads_address unmolested, causing an ICE later when we try to assign it to the reload reg. My guess would be that we need to be calling something other than find_reloads_address after replacing the subreg with the mem, but don't know reload well enough to say what.
Created an attachment (id=13445) [edit] Proposed patch I'm testing this patch on i686-pc-linux-gnu. If somebody can test it on ARM, that would be great.
Subject: Bug 28675 Author: ian Date: Fri Apr 27 05:11:47 2007 New Revision: 124211 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124211 Log: gcc/: PR target/28675 * reload.c (find_reloads_subreg_address): If the address was valid in the original mode but not in the new mode, reload the whole address. testsuite/: PR target/28675 * gcc.c-torture/compile/pr28675.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr28675.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 28675 Author: ian Date: Fri Apr 27 05:20:02 2007 New Revision: 124212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124212 Log: ./: PR target/28675 * reload.c (find_reloads_subreg_address): If the address was valid in the original mode but not in the new mode, reload the whole address. testsuite/: PR target/28675 * gcc.c-torture/compile/pr28675.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr28675.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/reload.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
Subject: Bug 28675 Author: ian Date: Fri Apr 27 05:45:53 2007 New Revision: 124213 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124213 Log: ./: PR target/28675 * reload.c (find_reloads_subreg_address): If the address was valid in the original mode but not in the new mode, reload the whole address. testsuite/: PR target/28675 * gcc.c-torture/compile/pr28675.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr28675.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
Fixed on 4.1 branch, 4.2 branch, and mainline.