Sun's javac trusts the platform JVM to correctly evaluate FP
arithmetic in its constant propagation. However, since Sun's own JVM
does this wrong on Pentium, it induces a bug in the compiler. An
earlier version of javac failed to specify that its constant folding
arithmetic was "strictfp", and thus would fail even with a conforming
VM on Pentium.

This seems pretty startling to me, but apparently I'm not
the common case.

---------------------------------------------------------------

An older version of Sun's HotSpot would incorrectly optimize, after
some amount of program execution, the correct versions of Math.sin and
Math.cos into direct calls to the Pentium machine instructions FSIN
and FCOS. These are not mathematical sin and cos, nor are they
necessarily within 1 ulp of mathematical sin and cos, nor do they
correspond to what is specified for Java.

The next version of the Java specification declared that (for
java.lang.Math) substitution of machine instructions not bit- for-bit
equivalent to the original specification was ok, as long as the
results are within 1 ulp of mathematical sin and cos. Since there is
no hardware that fulfills this requirement, this was an empty
performance promise, and HotSpot's behavior was still a bug.

I have heard that some later version of HotSpot gets this right, but
as of 1.3.1-b24, Math.sin and Math.cos are still optimized into forms
that can be wrong in as many as about 40 bits of the 53-bit mantissa.
You can see the change if you repeatedly evaluate cos(PI/2 + epsilon)
and sin(PI + epsilon), taking care to do it in a way that is not
easily made loop-invariant (else the bug will get optimized away).