[PATCH] add inputs to auto-libm-test-in yielding larger errors

Paul Zimmermann Paul.Zimmermann@inria.fr
Tue Dec 1 10:29:10 GMT 2020


       Dear Joseph,

> Date: Mon, 30 Nov 2020 22:21:24 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> 
> On Mon, 30 Nov 2020, Paul Zimmermann wrote:
> 
> >        Dear Joseph,
> > 
> > submitted as https://sourceware.org/bugzilla/show_bug.cgi?id=26982, and a
> > similar one for tgamma (https://sourceware.org/bugzilla/show_bug.cgi?id=26983).
> 
> Thanks.  It would be interesting to know if similar cases can be found for 
> other floating-point formats (inputs with large errors for different 
> formats could go in the same bugs rather than needing a separate bug for 
> each format) as that might affect how many implementations need to get 
> similar fixes.  You've done exhaustive searches for float.  But have you 
> looked for such large errors for these functions for ldbl-96 (x86 extended 
> precision) or ldbl-128 (binary128), for example?  (Or for ldbl-128ibm, 
> with the larger threshold of permitted errors there and the definition of 
> ulps that treats it like a format with exactly 106 bits of precision.)

so far I plan to look for large errors for binary32, binary64 and binary128,
for the 6 following libraries: glibc, Intel Math Library, AMD Libm, Redhat
newlib, OpenLibm and Musl (as far as I know only glibc and the Intel Math
Library do support binary128), on x86_64. I also plan to deal with bivariate
functions (pow, atan2, hypot). I will publish the largest errors found (with
corresponding inputs), as I already did for binary32.

For other formats, it should be easy to adapt my search program. If someone
is interested to help with ldbl-96 or ldbl-128ibm, please tell me and I will
send you my program.

Paul



More information about the Libc-alpha mailing list