This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/50762] ICE: in extract_insn, at recog.c:2137 (unrecognizable insn)
- From: "uweigand at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 08 Nov 2011 16:00:36 +0000
- Subject: [Bug rtl-optimization/50762] ICE: in extract_insn, at recog.c:2137 (unrecognizable insn)
- Auto-submitted: auto-generated
- References: <bug-50762-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762
--- Comment #4 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-11-08 16:00:36 UTC ---
It seems to me (part of) the problem is that the operand constraint is too
generic here:
(define_insn "*lea_4_zext"
[(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
(match_operand:SI 1 "lea_address_operand" "p")))]
"p" accepts any legitimate address operand, including const_int. But those are
then not actually accepted by the overall pattern (due to the mode check).
When reloading within an address operand, reload verifies only the constraint;
it does not expect the case where a constraint accepts something that is later
rejected by some other check.
One fix might be to use a more specific constraint here that does not accept
const_int.