Fix acosh (1) in round-downward mode (bug 16927).

According to C99 and C11 Annex F, acosh (1) should be +0 in all
rounding modes.  However, some implementations in glibc wrongly return
-0 in round-downward mode (which is what you get if you end up
computing log1p (-0), via 1 - 1 being -0 in round-downward mode).
This patch fixes the problem implementations, by correcting the test
for an exact 1 value in the ldbl-96 implementation to allow for the
explicit high bit of the mantissa, and by inserting fabs instructions
in the i386 implementations; tests of acosh are duly converted to
ALL_RM_TEST.  I believe all the other sysdeps/ieee754 implementations
are already OK (I haven't checked the ia64 versions, but if buggy then
that will be obvious from the results of test runs after this patch is
in).

Tested x86_64 and x86 and ulps updated accordingly.

	[BZ #16927]
	* sysdeps/i386/fpu/e_acosh.S (__ieee754_acosh): Use fabs on x-1
	value.
	* sysdeps/i386/fpu/e_acoshf.S (__ieee754_acoshf): Likewise.
	* sysdeps/i386/fpu/e_acoshl.S (__ieee754_acoshl): Likewise.
	* sysdeps/ieee754/ldbl-96/e_acoshl.c (__ieee754_acoshl): Correct
	for explicit high bit of mantissa when testing for argument equal
	to 1.
	* math/libm-test.inc (acosh_test): Use ALL_RM_TEST.
	* sysdeps/i386/fpu/libm-test-ulps: Update.
	* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.

1 files changed, 1 insertions, 0 deletions

diff --git a/sysdeps/i386/fpu/e_acosh.S b/sysdeps/i386/fpu/e_acosh.S
index 98a329179b..c66781c985 100644
--- a/sysdeps/i386/fpu/e_acosh.S
+++ b/sysdeps/i386/fpu/e_acosh.S
@@ -52,6 +52,7 @@ ENTRY(__ieee754_acosh)
 
 	// 1 <= x <= 2 => y = log1p(x-1+sqrt(2*(x-1)+(x-1)^2))
 	fsubl	MO(one)			// x-1 : log(2)
+	fabs				// acosh(1) is +0 in all rounding modes
 	fld	%st			// x-1 : x-1 : log(2)
 	fmul	%st(1)			// (x-1)^2 : x-1 : log(2)
 	fadd	%st(1)			// x-1+(x-1)^2 : x-1 : log(2)