On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > So, I wonder if we don't need to add a target hook where targets will be > able to provide upper bound on error for floating point functions for > different floating point modes and some way to signal unknown accuracy/can't > be trusted, in which case we would give up or return just the range for > VARYING.
Note that the figures given in the glibc manual are purely empirical (largest errors observed for inputs in the glibc testsuite on a system that was then used to update the libm-test-ulps files); they don't constitute any kind of guarantee about either the current implementation or the API, nor are they formally verified, nor do they come from exhaustive testing (though worst cases from exhaustive testing for float may have been added to the glibc testsuite in some cases). (I think the only functions known to give huge errors for some inputs, outside of any IBM long double issues, are the Bessel functions and cpow functions. But even if other functions don't have huge errors, and some architecture-specific implementations might have issues, there are certainly some cases where errors can exceed the 9ulp threshold on what the libm tests will accept in libm-test-ulps files, which are thus considered glibc bugs. (That's 9ulp from the correctly rounded value, computed in ulp of that value. For IBM long double it's 16ulp instead, treating the format as having a fixed 106 bits of precision. Both figures are empirical ones chosen based on what bounds sufficed for most libm functions some years ago; ideally, with better implementations of some functions we could probably bring those numbers down.)) -- Joseph S. Myers jos...@codesourcery.com
