Created attachment 18362 [details]
preprocessed, non-reduced test-case

Compile with -march=v32 -O2

(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.

patch posted.

Subject: Bug 41064

Author: hp
Date: Fri Aug 14 11:36:45 2009
New Revision: 150751

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150751
Log:
	PR rtl-optimization/41064
	* reload1.c (reload_as_needed): Don't call extract_insn
	for known invalid replacements after calling
	validate_replace_rtx_group and verify_changes.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/reload1.c

.

Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on this.

Not sure what's the state here.  Is 4.4 broken now?

(In reply to comment #7)
> Not sure what's the state here.  Is 4.4 broken now?

Here's the status as far as I know.  I had checked in a patch:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00254.html
to fix the problem PR 37053.  This patch introduced the regression
described in the current problem, fixed by Hans-Peter's patch above.

Now, *both* my PR 37053 patch and Hans-Peter's patch were checked in
only to mainline (i.e. GCC 4.5); GCC 4.4 should not be affected either
way.  However, this means the original problem in PR 37053 is still
present in GCC 4.4.  And in fact, it may well be the case that the
problem described in PR 40414 is actually a duplicate of PR 37053.

In this case, I guess the way to go would be to apply *both* my patch
and Hans-Peter's patch to the 4.4 branch ...

(In reply to comment #8)
> In this case, I guess the way to go would be to apply *both* my patch
> and Hans-Peter's patch to the 4.4 branch ...

I'm sorry I missed that the committed patch was fingered as a regressor (sp?).  Anyway the above approach sounds right.
The 4.4 branch results looks good for cris-elf in my autotester FWIW.

(In reply to comment #6)
> Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on this.

Looks like the above statement is wrong: the committed patch for this PR is just (one of the two) required for PR40414.  I'm closing this as there's no reason to hold *this* PR open regardless of the state of PR40414.

Changing back target milestone to reflect the earliest release known to have the fix.