This is the mail archive of the
mailing list for the GCC project.
Re: The state of glibc libm
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: libc-alpha at sourceware dot org, gcc at gcc dot gnu dot org
- Cc: Vincent Lefevre <vincent+gcc at vinc17 dot org>, Geert Bosch <bosch at adacore dot com>, Christoph Lauter <christoph dot lauter at lip6 dot fr>, bugdal at aerifal dot cx
- Date: Wed, 28 Mar 2012 15:18:16 +0000 (UTC)
- Subject: Re: The state of glibc libm
- References: <Pine.LNX.email@example.com>
On Wed, 29 Feb 2012, Joseph S. Myers wrote:
> I've reviewed many (not yet all) of glibc's open "math" component bugs. I
> hope some actual summary information on what the current state of libm
> looks like may be of interest to the people involved in the various past
> discussions of better libm for GCC or glibc - and those interested in
> fixing things, whether through patches to existing code, new
> implementations or both.
Here is an update on this analysis
<http://sourceware.org/ml/libc-alpha/2012-02/msg00772.html>, having now
reviewed all the open "math" component bugs and fixed quite a few of them
(and filed more bugs for issues found in the fixing process). Any glibc
libm bugs you know of that don't currently have an open bug filed in
Bugzilla should be filed there.
> (a) Most libm functions are not correctly rounded - and do not make an
> attempt at being correctly rounded.
> (b) Where functions do make attempts at being correctly rounded
> (especially the IBM Accurate Mathematical Library functions), they tend to
> be sufficiently slow that the slowness attracts bug reports. Again, this
> would likely be addressed by new implementations that use careful error
> bounds and information about worst cases to reduce the cost of being
> correctly rounding.
> (c) Various functions do not set errno correctly (many cases) or raise the
> proper floating-point exceptions (a smaller number of cases - both
> spurious exceptions where not permitted by ISO C, and failing to raise
> required overflow/underflow exceptions). In general this is a separate
> bug for each function (filed as many separate bugs in glibc Bugzilla) and
> can be fixed by a separate local patch for each function (adding a
> testcase, of course - note that glibc's main libm-test.inc presently only
> tests invalid and divide-by-zero exceptions, so if working on these error
> handling issues it might be useful to extend it to cover other exceptions
> as well as errno values).
Still present. libm-test.inc now tests for overflow exceptions as well as
invalid and divide-by-zero.
> (d) There are some specific bugs filed for functions such as nexttoward
> whose results are precisely specified by ISO C; in general these should be
> fixable by local patches.
Still present (some fixed, some other such bugs found).
> (e) Various functions, mainly IBM Accurate Mathematical Library ones,
> produce wildly wrong results or crash in non-default rounding modes. I
> have a patch for exp pending review at
> <http://sourceware.org/ml/libc-alpha/2012-02/msg00748.html> and I expect
> others can be fixed similarly.
> (f) Various trigonometrical functions are inaccurate on x86 and x86_64
> (see glibc bug 13658 and recent discussions).
> (g) Bessel function implementations handle large inputs in different ways
> to other functions, as I discuss at
> (h) Various complex functions have problems such as inaccuracy or wrong
> branch cuts.
Some fixed, others still present (though I don't think there are any wrong
branch cut issues after all).
> (i) Some real functions have particular issues (which should be fixable by
> local changes short of new correctly rounded implementations):
> - erfc (my patch
> <http://sourceware.org/ml/libc-alpha/2012-02/msg00640.html> is pending
> - pow (bugs 369, 706, 2678, 3866). The assembly implementations may
> complicate fixing these issues, though it's probably possible to fix
> only some bugs (in all relevant implementations, with plenty of
> testcases) rather than a patch needing to fix both all issues and all
> implementations at once.
Parts fixed, parts pending (bugs 706 and 13881).
> - lgamma, in cases where the result is close to 0 and there is a lot of
> cancellation in the present calculations.
> - tgamma, in cases of results of large magnitude (where the approach of
> using exp (lgamma) leads to large errors).
Still present. Some other issues with particular functions have also been
found since then.
Joseph S. Myers