We get the following ICE on m68k with gcc 4.1. I checked today's SVN and 4.1 fails while 4.2 works. (sid)34:tbm@usurper: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.1.2 -c -O kdelibs-slaveinterface.cpp kdelibs-slaveinterface.cpp: In function ‘QDataStream& operator<<(QDataStream&, const KIO::UDSEntry&)’: kdelibs-slaveinterface.cpp:62: error: unrecognizable insn: (insn 23 21 25 1 (set (mem/s/j/c:DI (plus:SI (reg/f:SI 26 virtual-stack-vars) (const_int -8 [0xfffffffffffffff8])) [0 a.m_long+0 S8 A16]) (ashiftrt:DI (mem/s/j:DI (plus:SI (reg:SI 31 [ D.1850 ]) (const_int 2 [0x2])) [0 <variable>.m_long+0 S8 A16]) (const_int 32 [0x20]))) -1 (nil) (nil)) kdelibs-slaveinterface.cpp:62: 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. (sid)35:tbm@usurper: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.1.2 -c kdelibs-slaveinterface.cpp (sid)36:tbm@usurper: ~] /usr/local/bin/m68k-linux-gnu-gcc-4.2.0 -c -O2 kdelibs-slaveinterface.cpp (sid)37:tbm@usurper: ~]
Created attachment 12027 [details] test case Testcase from application "kdelibs".
Broken since r102570: * expr.c (expand_expr_real_1): Do not load mem targets into register. * i386.c (ix86_fixup_binary_operands): Likewise. (ix86_expand_unary_operator): Likewise. (ix86_expand_fp_absneg_operator): Likewise. * optabs.c (expand_vec_cond_expr): Validate dest.
(In reply to comment #2) > Broken since r102570: That would mean a latent bug in the m68k back-end.
The removed comment says: - /* If will do cse, generate all results into pseudo registers - since 1) that allows cse to find more things - and 2) otherwise cse could produce an insn the machine - cannot support. An exception is a CONSTRUCTOR into a multi-word - MEM: that's much more likely to be most efficient into the MEM. - Another is a CALL_EXPR which must return in memory. */ So it looks like point 2 is true.
(In reply to comment #4) > So it looks like point 2 is true. So it is a latent bug in CSE.
Related to PR 27616.
Investigating.
> The removed comment says: > > - /* If will do cse, generate all results into pseudo registers > - since 1) that allows cse to find more things > - and 2) otherwise cse could produce an insn the machine > - cannot support. An exception is a CONSTRUCTOR into a multi-word > - MEM: that's much more likely to be most efficient into the MEM. > - Another is a CALL_EXPR which must return in memory. */ > > So it looks like point 2 is true. Except that CSE has not been run yet. :-) The problem is that the ashrdi3 expander is not matched by existing insns in the (MEM, MEM, CONST_INT) case. Either the predicates need to be tightened or one of the operands needs to be forced to a register in the preparation statements. While you're at it, please delete the 3 bogus comments added by Jeff as part of revision 24814: (define_expand "ashrdi3" [(set (match_operand:DI 0 "nonimmediate_operand" "") (ashiftrt:DI (match_operand:DI 1 "general_operand" "") (match_operand 2 "const_int_operand" "")))] "!TARGET_COLDFIRE" " { /* ??? This is a named pattern like this is not allowed to FAIL based on its operands. */ if (GET_CODE (operands[2]) != CONST_INT || ((INTVAL (operands[2]) < 1 || INTVAL (operands[2]) > 3) && INTVAL (operands[2]) != 8 && INTVAL (operands[2]) != 16 && (INTVAL (operands[2]) < 31 || INTVAL (operands[2]) > 63))) FAIL; } ") Of course expanders are allowed to fail in the preparation statements based on their operands, that's precisely why FAIL exists! See the example in the 13.15 section of the internals manual.
Closing 4.1 branch.