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.


More information about the Gcc mailing list