fp-bit bugs
Jeffrey A Law
law@cygnus.com
Sun Sep 20 06:39:00 GMT 1998
In message < 199809181812.UAA31976@sophie.matematik.su.se >you write:
> I decided to test fp-bit.c with random bit vectors as input. Not
> surprisingly, there are a number of errors remaining, given how much errors
> have been found in this code over the years.
>
> 1. 1/(-Inf) and (-1)/Inf should yield -0 but instead yield +0.
> 2. 7e-310/2.22 is improperly rounded. Lots of numbers with denormalized
> input or output yield improperly rounded quotients for both
> multiplication and division. The result is 1 ulp too small.
> 3. Incidentally, 7e-310*2.22 is also improperly rounded.
> 4. And so is 2.2805499343075318e-159/2.7653578282142482e+154. In this
> example, the output is a denormalized number.
> 5. An interesting example is 5.5568968730708003e-163*8.8888643361340676e-16
> 2
> where fp-bit computes the product as 0.0, and other IEEE implementations
> 4.9406564584124654e-324. (That last number is incidentally the smallest
> positive number an IEEE double can represent.)
>
> Here is a patch for the first problem. I am not working on fixing the other
> problems. It probably has to do with improper handling of the sticky bit
> when working on denorms. It is not terribly serious to get 1 ulp wrong
> for such numbers since denorms is a bug anyway.
>
> 1998-09-18 Torbjorn Granlund <tege@matematik.su.se>
>
> * fp-bit.c (pack_d): Do not clear SIGN when fraction is 0.
> (_fpadd_parts): Get sign right for 0.
Thanks. Installed.
jeff
More information about the Gcc
mailing list