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: "ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 09 Nov 2011 20:48:31 +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
Uros Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ubizjak at gmail dot com
--- Comment #9 from Uros Bizjak <ubizjak at gmail dot com> 2011-11-09 20:48:31 UTC ---
(In reply to comment #8)
> The zero_extend is a fixed part of the insn pattern in question:
>
> (define_insn "*lea_4_zext"
> [(set (match_operand:DI 0 "register_operand" "=r")
> (zero_extend:DI
> (match_operand:SI 1 "lea_address_operand" "p")))]
>
> Reload only ever changes what is *inside* the operands. It does not change the
> fixed parts of the pattern (outside of operands).
If this is the case, then (const_int 1) is perfectly acceptable here. It is
accepted as a valid address operand (most of the magic happens in
x86_decompose_address, followed by ix86_legitimate_address_p), and would result
in somehing like
leal 1(,1), %eax
0000000000000000 <.text>:
0: 8d 04 25 01 00 00 00 lea 0x1,%eax
Not quite effective way to load immediate 1, but whatnot.
> Not sure why that doesn't happen. I'll have a look.
Thanks!