re: Compiler bugs

Here's some that have bit me over the years.


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


Recent versions of Microsoft's Visual C++ compiler have
the following bugs:


1) apply distributive law to floating point arithmetic:


        a*b + a*c != a * (b+c)


2) improperly constant-propagates some of the odder
        FP values (e.g., NaN, -0.0)


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


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.


      static final double factor1 = (247.0/256.0) / two_to_the_535;
      static final long mantissa = 0x1010101010101L;
      static final double factor2 = (double) mantissa / two_to_the_535;
      static final double product = factor1 * factor2;


This can be seen by comparing the value of "product" after compilation
of javac running on a Sparc under Sun's VM, versus javac running on a
Pentium under Sun's VM.


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


The verifier in Sun's java fails to enforce static type- correctness
for interface types, see:


http://world.std.com/~chase/verify_problem.html


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


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


David Chase

Return to the comp.compilers page.
Search the comp.compilers archives again.