public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug math/18613] tgamma inaccurate in non-default rounding modes Date: Mon, 29 Jun 2015 23:30:00 -0000 [thread overview] Message-ID: <bug-18613-131-PVjOzbdtxm@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-18613-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=18613 --- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via e02920bc029019443326eecaa7b267b78ff2892e (commit) from 4aa10d01b654b7395c6e856b8e1e0959cfc80739 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e02920bc029019443326eecaa7b267b78ff2892e commit e02920bc029019443326eecaa7b267b78ff2892e Author: Joseph Myers <joseph@codesourcery.com> Date: Mon Jun 29 23:29:35 2015 +0000 Improve tgamma accuracy (bug 18613). In non-default rounding modes, tgamma can be slightly less accurate than permitted by glibc's accuracy goals. Part of the problem is error accumulation, addressed in this patch by setting round-to-nearest for internal computations. However, there was also a bug in the code dealing with computing pow (x + n, x + n) where x + n is not exactly representable, providing another source of error even in round-to-nearest mode; it was necessary to address both bugs to get errors for all testcases within glibc's accuracy goals. Given this second fix, accuracy in round-to-nearest mode is also improved (hence regeneration of ulps for tgamma should be from scratch - truncate libm-test-ulps or at least remove existing tgamma entries - so that the expected ulps can be reduced). Some additional complications also arose. Certain tgamma tests should strictly, according to IEEE semantics, overflow or not depending on the rounding mode; this is beyond the scope of glibc's accuracy goals for any function without exactly-determined results, but gen-auto-libm-tests doesn't handle being lax there as it does for underflow. (libm-test.inc also doesn't handle being lax about whether the result in cases very close to the overflow threshold is infinity or a finite value close to overflow, but that doesn't cause problems in this case though I've seen it cause problems with random test generation for some functions.) Thus, spurious-overflow markings, with a comment, are added to auto-libm-test-in (no bug in Bugzilla because the issue is with the testsuite, not a user-visible bug in glibc). And on x86, after the patch I saw ERANGE issues as previously reported by Carlos (see my commentary in <https://sourceware.org/ml/libc-alpha/2015-01/msg00485.html>), which needed addressing by ensuring excess range and precision were eliminated at various points if FLT_EVAL_METHOD != 0. I also noticed and fixed a cosmetic issue where 1.0f was used in long double functions and should have been 1.0L. This completes the move of all functions to testing in all rounding modes with ALL_RM_TEST, so gen-libm-have-vector-test.sh is updated to remove the workaround for some functions not using ALL_RM_TEST. Tested for x86_64, x86, mips64 and powerpc. [BZ #18613] * sysdeps/ieee754/dbl-64/e_gamma_r.c (gamma_positive): Take log of X_ADJ not X when adjusting exponent. (__ieee754_gamma_r): Do intermediate computations in round-to-nearest then adjust overflowing and underflowing results as needed. * sysdeps/ieee754/flt-32/e_gammaf_r.c (gammaf_positive): Take log of X_ADJ not X when adjusting exponent. (__ieee754_gammaf_r): Do intermediate computations in round-to-nearest then adjust overflowing and underflowing results as needed. * sysdeps/ieee754/ldbl-128/e_gammal_r.c (gammal_positive): Take log of X_ADJ not X when adjusting exponent. (__ieee754_gammal_r): Do intermediate computations in round-to-nearest then adjust overflowing and underflowing results as needed. Use 1.0L not 1.0f as numerator of division. * sysdeps/ieee754/ldbl-128ibm/e_gammal_r.c (gammal_positive): Take log of X_ADJ not X when adjusting exponent. (__ieee754_gammal_r): Do intermediate computations in round-to-nearest then adjust overflowing and underflowing results as needed. Use 1.0L not 1.0f as numerator of division. * sysdeps/ieee754/ldbl-96/e_gammal_r.c (gammal_positive): Take log of X_ADJ not X when adjusting exponent. (__ieee754_gammal_r): Do intermediate computations in round-to-nearest then adjust overflowing and underflowing results as needed. Use 1.0L not 1.0f as numerator of division. * math/libm-test.inc (tgamma_test_data): Remove one test. Moved to auto-libm-test-in. (tgamma_test): Use ALL_RM_TEST. * math/auto-libm-test-in: Add one test of tgamma. Mark some other tests of tgamma with spurious-overflow. * math/auto-libm-test-out: Regenerated. * math/gen-libm-have-vector-test.sh: Do not check for START. * sysdeps/i386/fpu/libm-test-ulps: Update. * sysdeps/x86_64/fpu/libm-test-ulps: Likewise. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 36 ++++ NEWS | 2 +- math/auto-libm-test-in | 10 +- math/auto-libm-test-out | 263 +++++++++++++++++++----------- math/gen-libm-have-vector-test.sh | 8 - math/libm-test.inc | 5 +- sysdeps/i386/fpu/libm-test-ulps | 36 ++++- sysdeps/ieee754/dbl-64/e_gamma_r.c | 87 +++++++--- sysdeps/ieee754/flt-32/e_gammaf_r.c | 88 +++++++--- sysdeps/ieee754/ldbl-128/e_gammal_r.c | 74 ++++++--- sysdeps/ieee754/ldbl-128ibm/e_gammal_r.c | 74 ++++++--- sysdeps/ieee754/ldbl-96/e_gammal_r.c | 74 ++++++--- sysdeps/x86_64/fpu/libm-test-ulps | 32 +++- 13 files changed, 540 insertions(+), 249 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2015-06-29 23:30 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-06-29 21:06 [Bug math/18613] New: " jsm28 at gcc dot gnu.org 2015-06-29 23:30 ` cvs-commit at gcc dot gnu.org [this message] 2015-06-29 23:31 ` [Bug math/18613] " jsm28 at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-18613-131-PVjOzbdtxm@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).