On 32-bit x86 (possibly depending on the processor), asin (-DBL_MIN), in FE_UPWARD mode, produces a result in the underflowing range. The mathematical result is slightly outside that range. testing double (without inline functions) Failure: asin_upward (-0x4p-1024): Exception "Underflow" set
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 046651c1688ff0eaa385d555dc4f24fd51a64460 (commit) from 003e49ed5d2034d73bfcf5324c461785687b7e88 (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=046651c1688ff0eaa385d555dc4f24fd51a64460 commit 046651c1688ff0eaa385d555dc4f24fd51a64460 Author: Joseph Myers <joseph@codesourcery.com> Date: Tue Mar 25 12:26:06 2014 +0000 Relax gen-auto-libm-tests may-underflow rules, test log1p in all rounding modes. gen-auto-libm-tests presently allows but does not require underflow exceptions for results with magnitude in the range (greatest subnormal, least normal]. In some cases, the magnitude of the exact result is very slightly above the least normal, but rounding in the implementation results in it effectively computing an infinite-precision result that is slightly below the least normal, so raising an underflow exception. This is in accordance with the documented accuracy goals, but results in testsuite failures. This patch changes the logic to allow underflows when the mathematical result is up to 0.5ulp above the least normal (so in any case where the round-to-nearest result is the least normal). Ideally underflows in all these cases would be accepted only when an underflow with the actual result is consistent with the rounding mode (in FE_TOWARDZERO mode, a return value of the least normal implies that the infinite-precision result did not underflow so there should be no underflow exception, for example), so as to match the documented goals more precisely - whereas at present the tests for exceptions are completely independent of the tests of the returned values. (The same applies to overflow exceptions as well - they too should be checked for consistency with the result, as in FE_TOWARDZERO mode a result 1ulp below the largest finite value should be inconsistent with an overflow exception and cause a failure with overflow rather than simply being considered a 1ulp error when overflow is expected.) But the present patch at least deals with the cases causing spurious failures so that (a) certain existing tests no longer need to be marked as having spurious exceptions (such markings in auto-libm-test-in end up applying to more cases than just those they are needed for) and (b) log1p can be tested in all rounding modes without introducing more such failures. This patch duly moves tests of log1p to ALL_RM_TEST. Tested x86_64 and x86 and ulps updated accordingly. [BZ #16357] [BZ #16599] * math/gen-auto-libm-tests.c (fp_format_desc): Add field min_plus_half. (fp_formats): Update initializers. (init_fp_formats): Initialize new field. (output_for_one_input_case): Allow underflow for results up to min_plus_half. * math/libm-test.inc (log1p_test): Use ALL_RM_TEST. * math/auto-libm-test-in: Don't mark some underflows from asin and atanh as spurious. * math/auto-libm-test-out: Regenerated. * sysdeps/i386/fpu/libm-test-ulps: Update. * sysdeps/x86_64/fpu/libm-test-ulps: Likewise. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 17 ++ NEWS | 8 +- math/auto-libm-test-in | 8 +- math/auto-libm-test-out | 558 ++++++++++++++++++------------------ math/gen-auto-libm-tests.c | 23 +- math/libm-test.inc | 4 +- sysdeps/i386/fpu/libm-test-ulps | 24 ++ sysdeps/x86_64/fpu/libm-test-ulps | 24 ++ 8 files changed, 367 insertions(+), 299 deletions(-)
The testsuite logic counting this as spurious has been fixed for 2.20 to be closer to the documented accuracy goals.