From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23840 invoked by alias); 28 Mar 2012 15:18:45 -0000 Received: (qmail 23811 invoked by uid 22791); 28 Mar 2012 15:18:40 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Mar 2012 15:18:25 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1SCude-0001hM-Kp from joseph_myers@mentor.com ; Wed, 28 Mar 2012 08:18:18 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Mar 2012 16:18:16 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1SCudc-00062E-3y; Wed, 28 Mar 2012 15:18:16 +0000 Date: Wed, 28 Mar 2012 15:18:00 -0000 From: "Joseph S. Myers" To: libc-alpha@sourceware.org, gcc@gcc.gnu.org cc: Vincent Lefevre , Geert Bosch , Christoph Lauter , bugdal@aerifal.cx Subject: Re: The state of glibc libm In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00441.txt.bz2 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 , 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. Still present. > (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. Still present. > (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 > and I expect > others can be fixed similarly. Fixed. > (f) Various trigonometrical functions are inaccurate on x86 and x86_64 > (see glibc bug 13658 and recent discussions). Fixed. > (g) Bessel function implementations handle large inputs in different ways > to other functions, as I discuss at > . Fixed. > (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 > is pending > review). Fixed. > - 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 joseph@codesourcery.com