[Bug target/50762] [4.7 Regression] ICE: in extract_insn, at recog.c:2137 (unrecognizable insn)

[uweigand at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50762

--- Comment #24 from Ulrich Weigand <uweigand at gcc dot gnu.org> 2011-11-11 13:04:02 UTC ---
(In reply to comment #22)

> Yeah, this is also what I thought at the first sight. But please don't forget
> that additional c-code test effectively creates
> 
> (and (match_operand (...)
>      (match_test (call to c-code)))
> 
> and this construct will _always_ force generation of mode checks.

No, it actually does not; see e.g. in the x86-64 insn-preds.c we have

(define_predicate "long_memory_operand"
  (and (match_operand 0 "memory_operand")
       (match_test "memory_address_length (op)")))

implemented as:

int
long_memory_operand (rtx op, enum machine_mode mode ATTRIBUTE_UNUSED)
{
  return (memory_operand (op, mode)) && (
#line 994 "../../gcc-head/gcc/config/i386/predicates.md"
(memory_address_length (op)));
}

This is because the genpred routines have code to follow boolean
operators and reason correctly that if match_operand performs the
mode test, and some other test is joined via "and", the test is
still not necessary.

In fact, except for the address_operand case, the mode checks seem
to be correct in their actual effect: we either call a standard operator
and omit the mode check, or else we have the genpred-generated mode check,
but in conjunction with some match_code test that excludes CONST_INT 
and CONST_DOUBLE anyway.