This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10
- From: "ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 15 Sep 2014 19:12:35 +0000
- Subject: [Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10
- Auto-submitted: auto-generated
- References: <bug-60704-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60704
UroÅ Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical
--- Comment #7 from UroÅ Bizjak <ubizjak at gmail dot com> ---
If LRA is able to fixup reg -> memory, as the comment above float patterns
claims, then constrain_operands should also recognize insn with memory-only
constraints, like:
(define_insn "*float<SWI48x:mode><MODEF:mode>2_i387"
[(set (match_operand:MODEF 0 "register_operand" "=f")
(float:MODEF (match_operand:SWI48x 1 "nonimmediate_operand" "m")))]
when register operand is passed as operand 1.
(I wonder why this pattern doesn't break in the same way as SSE version...)
Please note that these patterns are also present in 4.9 branch, and it looks to
me that the infrastructure is not fully prepared for the new LRA functionality.
It looks to me that we have critical issue here, so either the original patch
that introduced these patterns should be reverted, or infrastructure on release
branch should be fixed ASAP, before the new point release.