http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934
Chung-Lin Tang <cltang at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |cltang at gcc dot gnu.org
--- Comment #2 from Chung-Lin Tang <cltang at gcc dot gnu.org> 2010-12-23
10:09:29 UTC ---
I think this can be solved by changing the predicate of operand[2] in
*thumb1_addsi3 to "reg_or_int_operand". This allows later passes like reload to
do its job.
However, after the above change, I see another ICE during reload:
h.c:16:1: error: unrecognizable insn:
(insn 88 3 6 2 (set (reg:SI 3 r3)
(const_int 2147483648 [0x80000000])) h.c:5 -1
(nil))
h.c:16:1: internal compiler error: in extract_insn, at recog.c:2127
This turns out to be because, the generic 'general_operand' predicate used in
thumb1_movsi_insn does a "trunc_int_for_mode (INTVAL(op), mode) == INTVAL(op)"
test, and 0x80000000 (2147483648) gets negated due to the sign-extension in
trunc_int_for_mode(), failing the equality test:
trunc_int_for_mode(2147483648, SImode) == -2147483648 (0xFFFFFFFF80000000)
We can probably fix this by using another ARM predicate in this case, though
this boundary case of trunc_int_for_mode() is troubling, as the above
truncate-and-test-for-equality idiom seems quite common in the compiler.
