Created attachment 22704 [details] testcase Attached testcase when compiled with gcc trunk segfaults at O1/Os/O2 for arm $ arm-oe-linux-gnueabi-gcc -O2 -S a.c /net/isis/home/kraj/a.c: In function ‘bar’: /net/isis/home/kraj/a.c:11:1: error: unrecognizable insn: (insn 149 93 97 4 /net/isis/home/kraj/a.c:9 (set (reg:SI 271) (and:SI (subreg:SI (mem:HI (post_inc:SI (reg:SI 248 [ ivtmp.42 ])) [2 S2 A16]) 0) (const_int 255 [0xff]))) -1 (expr_list:REG_INC (reg:SI 248 [ ivtmp.42 ]) (nil))) a.c:11:1: internal compiler error: in extract_insn, at recog.c:2103 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. at Os/O1 it ICEs with internal compiler error: in elimination_costs_in_insn, at reload1.c:3639
I see these ICEs too with gcc-4.6-20101127 on armv5tel-linux-gnueabi.
This seems to appear at -march=armv5te .
Confirmed. A somewhat shorter testcase is: void bar (unsigned char *q, unsigned short *data16s, int len) { int i; for (i = 0; i < len; i++) { q[2 * i] = (((data16s[i] & 0xFF) << 8) | ((data16s[i] >> 8) & 0xFF)) & 0xFF; q[2 * i + 1] = ((unsigned short) (((data16s[i] & 0xFF) << 8) | ((data16s[i] >> 8) & 0xFF))) >> 8; } } The problem seems to be that an insn: (insn 88 86 90 4 (set (reg:SI 240) (zero_extend:SI (subreg:QI (mem:HI (post_inc:SI (reg:SI 220 [ ivtmp.22 ])) [2 MEM[(short unsigned int *)D.2066_62 + 4294967294B]+0 S2 A16]) 0))) a.c:10 152 {*arm_zero_extendqisi2} (expr_list:REG_INC (reg:SI 220 [ ivtmp.22 ]) (nil))) gets transformed by a splitter into: (insn 122 86 90 4 (set (reg:SI 240) (and:SI (subreg:SI (mem:HI (post_inc:SI (reg:SI 220 [ ivtmp.22 ])) [2 MEM[(short unsigned int *)D.2066_62 + 4294967294B]+0 S2 A16]) 0) (const_int 255 [0xff]))) a.c:10 -1 (expr_list:REG_INC (reg:SI 220 [ ivtmp.22 ]) (nil))) But this isn't accepted by the andsi3 pattern, since the (subreg (mem ..)) does not match the s_register_operand predicate. The splitter (define_split [(set (match_operand:SI 0 "register_operand" "") (zero_extend:SI (match_operand:QI 1 "register_operand" "")))] "!arm_arch6" [(set (match_dup 0) (ashift:SI (match_dup 2) (const_int 24))) (set (match_dup 0) (lshiftrt:SI (match_dup 0) (const_int 24)))] { operands[2] = simplify_gen_subreg (SImode, operands[1], QImode, 0); if (TARGET_ARM) { emit_insn (gen_andsi3 (operands[0], operands[2], GEN_INT (255))); DONE; } }) was introduced by Bernd Schmidt's patch to improve zero- and sign-extension handling on ARM (committed 2010-07-02), PR 42172: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00832.html Bernd, do you have any suggestions how to fix this?
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01096.html
Author: cltang Date: Thu Dec 16 05:10:18 2010 New Revision: 167900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167900 Log: 2010-12-16 Chung-Lin Tang <cltang@codesourcery.com> PR target/46883 * config/arm/arm.md (zero_extendhisi2 for register input splitter): Change "register_operand" to "s_register_operand". (zero_extendqisi2 for register input splitter): Same. testsuite/ * gcc.target/arm/pr46883.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/arm/pr46883.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
Chung-lin, your patch has been committed. Can this be closed now, or is there some outstanding problem?
GCC 4.6.0 is being released, adjusting target milestone.
Marking as fixed as I can see it fixed with 4.6.0 release , 4.6 branch, 4.7 branch and trunk.