CVS, fresh 'cvs update' run 2003-07-29 1630PDT. Created combined tree per the simtest-howto. Configured with "../combined/configure --target=xscale-elf --prefix=/usr/local/xscale --with-gnu-as --with-gnu-ld --with-newlib --disable-nls --enable-languages=c,c++" Ensuing make fails thus: make[6]: Entering directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/libstdc++-v3/src' [ snip ] /users/steve/gnu-toolchain/build.arm/gcc/xgcc -shared-libgcc -B/users/steve/gnu-toolchain/build .arm/gcc/ -nostdinc++ -L/users/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/libstdc++-v3/src -L/users/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/libstdc++-v3/src/.libs -nostdinc -B/u sers/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/newlib/ -isystem /users/steve/gnu-toolchai n/build.arm/xscale-elf/iwmmxt/newlib/targ-include -isystem /users/steve/gnu-toolchain/combined/ newlib/libc/include -B/usr/local/xscale/xscale-elf/bin/ -B/usr/local/xscale/xscale-elf/lib/ -is ystem /usr/local/xscale/xscale-elf/include -isystem /usr/local/xscale/xscale-elf/sys-include -L /users/steve/gnu-toolchain/build.arm/ld -mcpu=iwmmxt -nostdinc++ -I/users/steve/gnu-toolchain/b uild.arm/xscale-elf/iwmmxt/libstdc++-v3/include/xscale-elf -I/users/steve/gnu-toolchain/build.a rm/xscale-elf/iwmmxt/libstdc++-v3/include -I../../../../../combined/libstdc++-v3/libsupc++ -I.. /../../../../combined/libstdc++-v3/libmath -O2 -O -g -O2 -mcpu=iwmmxt -fno-implicit-templates - Wall -Wno-format -W -Wwrite-strings -fdiagnostics-show-location=once -c ../../../../../combined /libstdc++-v3/src/codecvt.cc -o codecvt.o ../../../../../combined/libstdc++-v3/src/codecvt.cc: In member function ` virtual int std::codecvt<char, char, mbstate_t>::do_length(mbstate_t&, const char*, const char*, long unsigned int) const': ../../../../../combined/libstdc++-v3/src/codecvt.cc:113: error: could not split insn (insn:HI 89 108 58 bits/stl_algobase.h:148 (parallel [ (set (reg/v/f:SI 2 r2 [orig:78 __b ] [78]) (if_then_else:SI (geu (reg:SI 3 r3 [81]) (reg:SI 1 r1 [84])) (plus:SI (reg:SI 0 r0) (const_int 4 [0x4])) (reg/v/f:SI 2 r2 [orig:78 __b ] [78]))) (clobber (reg:CC 24 cc)) ]) 228 {*ifcompare_plus_move} (insn_list 21 (insn_list 22 (insn_list 94 (insn_list 32 ( insn_list 95 (nil)))))) (expr_list:REG_DEAD (reg:SI 3 r3 [81]) (expr_list:REG_DEAD (reg:SI 1 r1 [84]) (expr_list:REG_DEAD (reg:SI 0 r0) (expr_list:REG_UNUSED (reg:CC 24 cc) (nil)))))) ../../../../../combined/libstdc++-v3/src/codecvt.cc:113: internal compiler error: in final_scan_insn, at final.c:2443 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[6]: *** [codecvt.lo] Error 1 make[6]: Leaving directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/libstdc++-v3 /src' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/libstdc++-v3 ' make[4]: *** [all-recursive-am] Error 2 make[4]: Leaving directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/iwmmxt/libstdc++-v3 ' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/libstdc++-v3' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/libstdc++-v3' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/users/steve/gnu-toolchain/build.arm/xscale-elf/libstdc++-v3' make: *** [all-target-libstdc++-v3] Error 2
Created attachment 4529 [details] preprocessed source Little bitty 151 line file sure gets large when preprocessed.
The failure is with -mcpu=iwmmxt, whose support was added 2003-06-18 by Nick Clifton. An xscale-elf cross cc1plus on i686-pc-linux-gnu from just after that support was added gets the same error when the attachment from comment #1 is compiled with "-mcpu=iwmmxt -O2 -g".
Taking Janis's comment as a confirming this problem.
Subject: Re: ICE "could not split insn" building libstdc++-v3 Hi Guys, The attached patch is a workaround for the problem. It disables the split that is causing the problems when the compiler is generating code for the iWMMXt. At the moment I have no idea why the split is not working properly, or why the problem should appear to be iWMMXt specific. I am still looking into this. Cheers Nick Index: gcc/config/arm/arm.md =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/arm/arm.md,v retrieving revision 1.140 diff -c -3 -p -r1.140 arm.md *** gcc/config/arm/arm.md 12 Jul 2003 23:02:22 -0000 1.140 --- gcc/config/arm/arm.md 8 Aug 2003 08:10:56 -0000 *************** *** 7043,7049 **** (match_operand:SI 3 "arm_add_operand" "rIL,rIL")) (match_operand:SI 1 "arm_rhs_operand" "0,?rI"))) (clobber (reg:CC CC_REGNUM))] ! "TARGET_ARM" "#" [(set_attr "conds" "clob") (set_attr "length" "8,12")] --- 7043,7049 ---- (match_operand:SI 3 "arm_add_operand" "rIL,rIL")) (match_operand:SI 1 "arm_rhs_operand" "0,?rI"))) (clobber (reg:CC CC_REGNUM))] ! "TARGET_ARM && !TARGET_IWMMXT" "#" [(set_attr "conds" "clob") (set_attr "length" "8,12")]
As evidenced by my disappearance for some time, the patch fixes it for me.
hi, additional comments I encountered with a similar issue like this, my gcc version is 2.95.1 19990816. It is interesting that when I commented some piece of my code, I could successfully compiling my file, so I just wonder whether is this file too large (68k),but there are some other files are larger than it. ==================================== atmDebug.cc: In function `void atmPmLogDisplay(unsigned int = 0, short unsigned int = 0, short unsigned int = 0)': atmDebug.cc:2519: Could not split insn (insn:TI 520 517 521 (parallel[ (set (reg:CC 71 cr3) (compare:CC (sign_extend:SI (reg:HI 0 r0)) (const_int 0))) (clobber (reg:SI 9 r9)) ] ) 71 {extendhisi2+2} (insn_list 517 (insn_list 517 (nil))) (expr_list:REG_DEAD (reg:HI 0 r0) (expr_list:REG_UNUSED (reg:SI 9 r9) (nil)))) ../../src/gcc/toplev.c:1472: Internal compiler error in function fatal_insn Please submit a Problem Report to Cygnus Solutions with send-pr.
Ping! Nick, is there still a bug to fix here? The pattern you hacked in comment #4 is still not fixed AFAICT.
moving to WAITING pending Nick's reply.
Hi Steven, There is no longer a buf to fix. In fact the hack mentioned in comment #4 has been removed and the test case compiles without problems using the current mainline sources. Cheers Nick
Reported as fixed, see comment #9.