[Bug 237800] pow(3) returns inaccurate results

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237800

            Bug ID: 237800
           Summary: pow(3) returns inaccurate results
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: misc
          Assignee: bugs at FreeBSD.org
          Reporter: khw at cpan.org
 Attachment #204271 text/plain
         mime type:

Created attachment 204271
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=204271&action=edit
Reproducer .c

The attached essentially one-liner, program prints 0x1.431e0fae6d722p+96
on FreeBSD 13 clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
LLVM 8.0.0)

On Linux, it prints 0x1.431e0fae6d721p+96
a difference of 1 in the final hex digit of the mantissa.  The Linux version is
the correct value.
We are getting identical failures on 11.2, 12.0, and Open BSD 6.4

http://www.cpantesters.org/distro/M/Math-Clipper.html?grade=3&perlmat=1&patches=2&oncpan=2&distmat=2&perlver=ALL&osname=ALL&version=1.27

I work on maintaining and extending the Perl 5 programming language.  We made a
change earlier in our current development cycle that improved the accuracy of
converting a string representing a floating point number into an equivalent
double precision C value.  We now use strtod() instead of atof().  That broke
the module Math::Clipper.  It turns out it was relying on the imprecision of
atof() to work around this pow() bug.  That work around was added in May 2018.

The above smoke reports rely on a volunteer network of people to do the
testing.  That means the coverage of a module such as Math::Clipper is spotty. 
Probably it's failing Open BSD in other versions of Perl, but those just didn't
get tested.

-- 
You are receiving this mail because:
You are the assignee for the bug.