3 Jan 2002 16:38:41 -0500

Related articles |
---|

re: Compiler bugs chase@world.std.com (David Chase) (2002-01-03) |

Re: Compiler bugs Peter-Lawrence.Montgomery@cwi.nl (2002-01-05) |

Re: Compiler bugs christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-05) |

Re: Compiler bugs chase@world.std.com (David Chase) (2002-01-14) |

Re: Arithmetic accuracy, was Compiler bugs joachim_d@gmx.de (Joachim Durchholz) (2002-01-16) |

Bit-exact floating-point computations fare+NOSPAM@tunes.org (Francois-Rene Rideau) (2002-01-17) |

Re: floating point accuracy, was Compiler bugs christian.bau@cbau.freeserve.co.uk (Christian Bau) (2002-01-17) |

[11 later articles] |

From: | David Chase <chase@world.std.com> |

Newsgroups: | comp.compilers |

Date: | 3 Jan 2002 16:38:41 -0500 |

Organization: | Compilers Central |

Keywords: | errors |

Posted-Date: | 03 Jan 2002 16:38:41 EST |

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

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.