Re: Compiler bugs

Christian Bau <>
5 Jan 2002 01:41:34 -0500

          From comp.compilers

Related articles
re: Compiler bugs (David Chase) (2002-01-03)
Re: Compiler bugs (2002-01-05)
Re: Compiler bugs (Christian Bau) (2002-01-05)
Re: Compiler bugs (David Chase) (2002-01-14)
Re: Arithmetic accuracy, was Compiler bugs (Joachim Durchholz) (2002-01-16)
Bit-exact floating-point computations (Francois-Rene Rideau) (2002-01-17)
Re: floating point accuracy, was Compiler bugs (Christian Bau) (2002-01-17)
Re: floating point accuracy, was Compiler bugs (2002-01-18)
Re: Bit-exact floating-point computations (Christian Bau) (2002-01-18)
[33 later articles]
| List of all articles for this month |

From: Christian Bau <>
Newsgroups: comp.compilers
Date: 5 Jan 2002 01:41:34 -0500
Organization: Compilers Central
References: 02-01-015
Keywords: errors
Posted-Date: 05 Jan 2002 01:41:33 EST

David Chase wrote:
> 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.

This changed specification has two consequences:

1. You can produce slightly faster code for example on a PowerPC. The
implementation of sine/cosine is now allowed for example to use fused
multiply/add instructions and get results that are not bit for bit
identical, but as good as the specification.

2. On a Pentium, you can implement sine/cosine by doing a quick check
for hard values and using FSIN/FCOS in cases where you can guarantee
they give results within 1 ulp and do it the hard way in other cases.
For example, FSIN has an error < 1ulp for small values unless they are
close to pi, 2pi, 3pi etc.

Of course, just using FSIN/FCOS is still not correct.

Post a followup to this message

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