SPECjbb vs. 3.1 status

SPECjbb vs. 3.1 status

[Boehm, Hans]

I think I now understand all the issues still affecting SPECjbb and gcc3.1
on X86 (IA64 is fine):

0) GNATS 6411 and 6382 force some of the sanity tests to be commented out.

1) The ICEs at reload1.c:9514 reported in
http://gcc.gnu.org/ml/java/2002-04/msg00253.html are still there.  For 3.1
only, should we replace the offending "abort();" by a "continue;"?  This
seems to work around the problem, at least for examples similar to the ones
I've seen.  I have mixed feelings about it, since I'm not sure how likely it
is to turn an ICE into silentely emitted wrong code.

2) Floating point operations are generally carried out at the wrong
precision on X86.  AFAICT, the fp control word specifies extended precision
operation, but the JLS requires that we never use more than double precision
(though we may use bigger exponents if strictfp isn't specified).  This
causes the following program to print 8 instead of 9.  (I claim that if you
write this code, you have no real reason to expect either answer.  Double
precision happens to work out such that you get the more intuitive answer.
Extended precision doesn't, particularly since the constant is only
generated at double precision.)  Unless there is a really easy way to fix
this, I think this will have to wait for a later release.  I'm not sure what
the intended conventions are about the control word.

Test case:

public class fp_test {
    private int m;
    private int n;
    fp_test(int k) {
	if (k < 5) {
	  m = 30;
	} else {
	  m = 0;
	}
	n = (short)(m * 0.30);
    }
    public static void main(String argv[]) {
	fp_test fpt = new fp_test(0);
	System.out.println(fpt.n);
    }
}

This affects SPECjbb in that a random number generator may be invoked the
wrong number of times, thus causing the results to vary.  It also turns out
it tickles what I think is a bug in the source.  (The bug doesn't affect the
utility of the benchmark.  But it seems to magnify rounding errors in
unintended ways.)

Hans