about summary refs log tree commit diff
path: root/ctype/ctype.c
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2014-02-18 14:45:41 +0000
committerJoseph Myers <joseph@codesourcery.com>2014-02-18 14:45:41 +0000
commita4fb786185fce5048a13c7879f67dfbe59ff70be (patch)
tree32d90a80cb679c5d96320ec56b92928312e1246e /ctype/ctype.c
parentef114eafbff80525d079d7d6fadd69a58eb8dcc3 (diff)
downloadglibc-a4fb786185fce5048a13c7879f67dfbe59ff70be.tar.gz
glibc-a4fb786185fce5048a13c7879f67dfbe59ff70be.tar.xz
glibc-a4fb786185fce5048a13c7879f67dfbe59ff70be.zip
Fix gen-auto-libm-tests sticky bit setting for negative results.
gen-auto-libm-tests has a bug in the logic for setting a sticky bit
based on the ternary value from MPFR: it is correct for positive
results, but for negative results mpz_setbit acts as if a two's
complement representation is used, whereas the low bit needs setting
based on the sign-magnitude representation GMP actually uses.  (This
showed up in converting fma tests to use auto-libm-test-in /
gen-auto-libm-tests.)

This patch fixes the problem by negating the mpz_t value to set its
low bit.  There are lots of changes to auto-libm-test-out (mainly 1ulp
fixes to ldbl-128 expected results), but only a few ulps updates are
needed on x86 / x86_64.  In one case, a corrected expectation showed
up a spurious underflow exception where the correct result is slightly
outside the underflowing range.

Tested x86_64 and x86 and ulps updated accordingly.

	* math/gen-auto-libm-tests.c (adjust_real): Ensure integers are
	non-negative before setting low bit.
	* math/auto-libm-test-in: Mark one asin test possibly having
	spurious underflow.
	* math/auto-libm-test-out: Regenerated.
	* sysdeps/i386/fpu/libm-test-ulps: Update.
	* sysdeps/x86_64/fpu/libm-test-ulps: Likewise.
Diffstat (limited to 'ctype/ctype.c')
0 files changed, 0 insertions, 0 deletions