Re: floating point woes on i386

[Greg Troxel <gdt%lexort.com@localhost>]

mlelstv%serpens.de@localhost (Michael van Elst) writes:

> gdt%lexort.com@localhost (Greg Troxel) writes:
>
>>I ran paranoia (pkgsrc/benchmarks/paranoia) on 9 and 10.  On 9:
>
>>  The number of  FAILUREs  encountered =       3.
>>  The number of  SERIOUS DEFECTs  discovered = 4.
>>  The number of  DEFECTs  discovered =         3.
>>  The number of  FLAWs  discovered =           2.
>
>>which is shocking, especially as I remember earlier NetBSD i386 versions
>>being ok, like 5 or 7.
>
> Same on -10, but while some defects are strange (like not
> obeying rules for -inf and nan), some show a problem of
> paranoia.
>
> DEFECT:  computing
>         (1.30000000000000000e+01) ^ (1.70000000000000000e+01)
>         yielded 8.65041591938133811e+18;
>         which compared unequal to correct 8.65041591938133914e+18 ;
>                 they differ by -1.02400000000000000e+03 .
>
> 13^17 is an integer with 19 digits that needs 126 bit (without
> the leading 1).
>
> 13^17 = 8650415919381337933  the real value
>       = 8650415919381338110  what paranoia thinks was computed
>       = 8650415919381339140  what paranoia believed to be correct
>
> For comparison:
>
> 13^17 = 8650415977864888320  when multiplying 13.0 17 times with float.
>         8650415919381339136  when multiplying 13.0 17 times with double.
>         8650415919381337933  when multiplying 13.0 17 times with long double.
>         8650415919381338112  what paranoia really computed == pow(13.0, 17.0).

I guess that's a complicated situation in terms of IEEE754 and the
expected deterministic outcome, but if we are down to just that it would
be great :-)

> Running the 32bit and the 64bit version of paranoia on the same
> hardware also reveals:
>
> 32bit:
> Radix = 2.000000 .
> Closest relative separation found is U1 = 5.4210109e-20 .
> The number of significant digits of the Radix is 64.000000 .
>
> 64bit:
> Radix = 2.000000 .
> Closest relative separation found is U1 = 1.1102230e-16 .
> The number of significant digits of the Radix is 53.000000 .
>
> At least the precision calculations are spoiled by verifying only
> at a lower precision on 64bit. My guess is that the paranoia
> diagnosis would be 'better' when compiling paranoia (and maybe
> libm) with -ffloat-store.

I rebuilt paranoia with -ffloat-store (and didn't touch libm), and then
I get only:

  Checking rounding on multiply, divide and add/subtract.
  * is neither chopped nor correctly rounded.
  / is neither chopped nor correctly rounded.
  Addition/Subtraction neither rounds nor chops.
  Sticky bit used incorrectly or not at all.
  FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
  (noted above) count as one flaw in the final tally below.

I see a complaint about * and correct rounding on 10-aarch64, and no
complaints at all on 10-amd64.


Does our amd64 build avoid the use of extended (80-bit) doubles?

Assuming no and no, do you understand why the IEEE754-expected 53 bits
is found on amd64?  Is that just happenstance of how the test is
compiled?