There were two major patches which went in during this time.  The CFG inliner and the Jeff Law's patch, 
either could have caused this.

We obviously need the preprocessed source.

In response to comment #2, this is a combined tree, so the sources are trivially
available for all and you shouldn't need to be handed preprocessed code
separately.  Having said that, I'll attach preprocessed versions hoping for a
quick resolution.

Created attachment 8919 [details]
Preprocessed code

Options to cc1 from -v: -fpreprocessed hash.i -melf -ffunction-sections
-fdata-sections -quiet -dumpbase hash.c -march=v10 -mbest-lib-options
-march=v10 -mbest-lib-options -auxbase hash -g -O2 -O2 -O2 -version
-fno-builtin -o hash.s

Shorter: -march=v10 -O2 -o hash.s -fpreprocessed hash.i

(In reply to comment #3)

> In response to comment #2, this is a combined tree, so the
> sources are trivially available for all and you shouldn't need 
> to be handed preprocessed code separately.  

I am sorry but this is what our rules say. There is no exception for free code 
bases where the bugmaster/bugfixer could potentially download and build the 
package himself. Whoever reported the bug can surely build the preprocessed 
source much faster than who happens to see the report. I believe this is a 
sound rule.

> Having said that, I'll attach preprocessed versions hoping for a
> quick resolution.

Thanks.

Hmm, the SSA_NAME is in the free list for some reason.  

Confirmed, reduced testcase:
typedef struct hashhdr {
 int bitmaps[32];
} HASHHDR;

static void
swap_header_copy(HASHHDR *srcp, HASHHDR *destp)
{
  int i;
  for (i = 0; i < 32; i++)
    ((char *)&(destp->bitmaps[i]))[0] = ((char *)&(srcp->bitmaps[i]))[1];
}

int
flush_meta(HASHHDR *whdrp1)
{
 HASHHDR *whdrp;
 HASHHDR whdr;
 whdrp = &whdr;
 swap_header_copy(whdrp1, whdrp);
 return (0);
}

This is independent of target/host.  My testcase gives a different ICE:
pr21638.c:15: error: Definition in block 1 does not dominate use in block 0
for SSA_NAME: i.0_10 in statement:
D.1281_1 = &whdr.bitmaps[i.0_10];
pr21638.c:15: internal compiler error: verify_ssa failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

In reply to comment #3:
No, I don't think your reading of what rules you refer to is "sane",
but then perhaps you're not used to building a unified tree for cross
toolchains, re: simtest-howto.html.  If you'd done that with any regularity,
then you'd have all the bits and would not see newlib as "free code bases to
download yourself".  I stand by this; I think it can be expected that people
test with cross toolchains, for better test coverage than just their "native"
machines.

(In reply to comment #9)
> In reply to comment #3:
Usually I just say "please attach it because I am too lazy to build an unified tree" instead of saying this 
goes against our rules.  Anyways I am trying to figure out a way to fix this, the problem is that forward 
prograte is making an ADDR_EXPR still invariant when it is obviously not.

Mine, I have a fix.

*** Bug 21648 has been marked as a duplicate of this bug. ***

Index: tree-ssa-forwprop.c
===============================================================
====
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-forwprop.c,v
retrieving revision 2.17
diff -u -p -r2.17 tree-ssa-forwprop.c
--- tree-ssa-forwprop.c	18 May 2005 16:49:49 -0000	2.17
+++ tree-ssa-forwprop.c	18 May 2005 22:02:21 -0000
@@ -495,6 +495,7 @@ forward_propagate_addr_into_variable_arr
   /* Replace the pointer addition with array indexing.  */
   TREE_OPERAND (use_stmt, 1) = unshare_expr (TREE_OPERAND (stmt, 1));
   TREE_OPERAND (TREE_OPERAND (TREE_OPERAND (use_stmt, 1), 0), 1) = index;
+  recompute_tree_invarant_for_addr_expr (TREE_OPERAND (use_stmt, 1));
 
   /* That should have created gimple, so there is no need to
      record information to undo the propagation.  */
@@ -623,6 +624,8 @@ forward_propagate_addr_expr (tree stmt)
 	{
 	  mark_new_vars_to_rename (use_stmt);
 	  update_stmt (use_stmt);
+	  if (TREE_CODE (rhs) == ADDR_EXPR)
+	    recompute_tree_invarant_for_addr_expr (rhs);
 	  return true;
 	}
       else

The patch in comment #13 works; build completes for cris-elf and testsuite
results seem sane (same "new failures" as cris-axis-linux-gnu before this
patch).  Also tested on mmix-knuth-mmixware, no regressions (no changes at all).

HP: people are expected to provide preprocessed source code even for bootstrap 
failures, let alone unified source tree builds for fancy platforms. This very 
bug shows how providing a preprocessed source made a quick fix possible.

So what are you exactly complaining for? If you want a bug fixed, be helpful 
like everybody does. The fact that you are a maintainer does not buy you to 
shortcut rules and expect people to do the work in your place.

Subject: Re:  [4.1 regression] ADDR_EXPR invariancy
 not recomputed

On Thu, 19 May 2005, giovannibajo at libero dot it wrote:
> ------- Additional Comments From giovannibajo at libero dot it  2005-05-19 10:10 -------
> HP: people are expected to provide preprocessed source code even for bootstrap
> failures, let alone unified source tree builds for fancy platforms. This very
> bug shows how providing a preprocessed source made a quick fix possible.

Certainly, but it would have been even quicker if people were
already having simulator toolchains at hand, for testing their
patches or to verify bugs.  Thus I somewhat thought all
"bugmasters" would be familiar enough with them; hopefully using
them, but at least not one accusing me that I "shortcut rules"
when not immediately providing preprocessed source for a target
library there.

Newlib *is* special; it's part of the toolchain and builds
naturally together with simulator, binutils and gcc in one fell
swoop.  Much like one of the target libraries provided with gcc.
Would you ask people for preprocessed source for, say, libgcc?
Hm, maybe you would, by your indication of "bootstrap failures".

> So what are you exactly complaining for?

What complaint?  I'm replying to *your* complaint, and attempt
to lecture me on your interpretation of some "rule" you read,
presumably that we ask people for preprocessed source when
reporting bugs.

> If you want a bug fixed, be helpful
> like everybody does.

Eh, I think I was/did. :-)

> The fact that you are a maintainer does not buy you to
> shortcut rules and expect people to do the work in your place.

What?  Where did you get *that* from?  I resent that accusation!
I certainly don't expect bugs to be fixed just because I report
them in bugzilla.  I also don't expect a bugmaster to start an
inproductive argument, but that might be just because I'm a
maintainer. ;-)

I never expect people to fix a bug exposed by the targets I
maintain unless they're the one that made the bug or to some
extent when they write code that expose a bug.  So many thanks
to pinskia!  Much unexpected, very much appreciated.

Worth the enormous amount of work it takes to upload the
preprocessed sources. ;-)

brgds, H-P

A patch was posted by Richard Sandiford:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html

Fixed.

*** Bug 21780 has been marked as a duplicate of this bug. ***