I found one last SPARC issue, this time with the falign() function.

This one was a pain to track down because gdb won't let you show the %gsr 
register, or any of the floating point registers above %f32.

The falign code does this:

      tmp = (*((uint64_t *)&DT0)) << ((env->gsr & 7) * 8);
      tmp |= (*((uint64_t *)&DT1)) >> (64 - (env->gsr & 7) * 8);

But in the case where %gsr is zero, the second case turns into a
shift left of 64, which on many architectures turns into a no-op (rather 
than clearning the result to zero).

So in this case, the output of the falign was rs1 *or'd* with rs2, rather 
than just plain rs1.

I've included a patch below that fixes things for me, and I've also 
attached a test case that shows the bug.

With this, I can finally run the spec 2006 bzip2 benchmark to completion 
under sparc32plus-linux-user

Vince

--- op_helper.c.orig	2008-07-29 22:38:34.000000000 -0400
+++ op_helper.c	2008-08-06 15:24:51.000000000 -0400
@@ -234,7 +234,12 @@
      uint64_t tmp;

      tmp = (*((uint64_t *)&DT0)) << ((env->gsr & 7) * 8);
-    tmp |= (*((uint64_t *)&DT1)) >> (64 - (env->gsr & 7) * 8);
+ 
+       /* on many architectures a shift of 64 does nothing */
+    if ( (env->gsr & 7) !=0) {
+       tmp |= (*((uint64_t *)&DT1)) >> (64 - (env->gsr & 7) * 8);
+    }
+
      *((uint64_t *)&DT0) = tmp;
  }