------- Comment #2 from hp at gcc dot gnu dot org 2009-08-14 02:19 -------
(In reply to comment #0)
> A brief look with gdb reveals the immediate cause of the ICE is the
> extract_insn call in the context of the change of revision 150726. Applying it
> to a non-recognizable insn, a no-no. I don't quite understand why this didn't
> also happen before revision 150726 as the same call was there then too,
A major difference between validate_replace_rtx (r150725) and
validate_replace_rtx_group (r150726) that's called just before extract_insn for
both revisions is that validate_replace_rtx restores replacements if they are
seen as invalid, so the extract_insn only happens for a this-far-known valid
and recognizable insn. So, assuming that r150726 is otherwise correct, it
needs to be adjusted with this patch (moving the extract_insn call to inside
the truth-arm of the validity-test that follows plus a warning comment):
Index: reload1.c
===================================================================
--- reload1.c (revision 150626)
+++ reload1.c (working copy)
@@ -4312,10 +4312,15 @@
n = verify_changes (0);
/* We must also verify that the constraints
- are met after the replacement. */
- extract_insn (p);
+ are met after the replacement. Make sure
+ extract_insn is only called for an insn
+ where the replacements were found to be
+ valid so far. */
if (n)
- n = constrain_operands (1);
+ {
+ extract_insn (p);
+ n = constrain_operands (1);
+ }
/* If the constraints were not met, then
undo the replacement, else confirm it. */
I'm going to test this and submit it.
--
hp at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-08-14 02:19:34
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41064
