svn commit: r215237 - head/lib/msun/src

[Bruce Evans]

On Mon, 15 Nov 2010, Alexander Best wrote:

> also it seems one of the regression tests in tools/regression/lib/msun fails
> (assert tripped): test-lrint.

I get this on amd64, and lots more failures starting with csqrt() on
i386.  Here is the output of make >foo 2>&1, after adding "set +e; "
to the loop in the Makefile so that the shell loop doesn't abort on
the first failure:

% set +e; for p in test-conj test-csqrt test-exponential test-fenv test-fma  test-fmaxmin test-ilogb test-invtrig test-lrint  test-lround test-nan test-next test-rem test-trig; do /dumpster/home/bde/q/src/tools/regression/lib/msun/$p; done
% 1..42
% ok 1		# conjf(0.0 + 0.0I)
% ok 2		# conj(0.0 + 0.0I)
% ok 3		# conjl(0.0 + 0.0I)
% ok 4		# conjf(0.0 + 1.0I)
% ok 5		# conj(0.0 + 1.0I)
% ok 6		# conjl(0.0 + 1.0I)
% ok 7		# conjf(1.0 + 0.0I)
% ok 8		# conj(1.0 + 0.0I)
% ok 9		# conjl(1.0 + 0.0I)
% ok 10		# conjf(-1.0 + 0.0I)
% ok 11		# conj(-1.0 + 0.0I)
% ok 12		# conjl(-1.0 + 0.0I)
% ok 13		# conjf(1.0 + -0.0I)
% ok 14		# conj(1.0 + -0.0I)
% ok 15		# conjl(1.0 + -0.0I)
% ok 16		# conjf(0.0 + -1.0I)
% ok 17		# conj(0.0 + -1.0I)
% ok 18		# conjl(0.0 + -1.0I)
% ok 19		# conjf(2.0 + 4.0I)
% ok 20		# conj(2.0 + 4.0I)
% ok 21		# conjl(2.0 + 4.0I)
% ok 22		# conjf(0.0 + infI)
% ok 23		# conj(0.0 + infI)
% ok 24		# conjl(0.0 + infI)
% ok 25		# conjf(0.0 + -infI)
% ok 26		# conj(0.0 + -infI)
% ok 27		# conjl(0.0 + -infI)
% ok 28		# conjf(inf + 0.0I)
% ok 29		# conj(inf + 0.0I)
% ok 30		# conjl(inf + 0.0I)
% ok 31		# conjf(nan + 1.0I)
% ok 32		# conj(nan + 1.0I)
% ok 33		# conjl(nan + 1.0I)
% ok 34		# conjf(1.0 + nanI)
% ok 35		# conj(1.0 + nanI)
% ok 36		# conjl(1.0 + nanI)
% ok 37		# conjf(nan + nanI)
% ok 38		# conj(nan + nanI)
% ok 39		# conjl(nan + nanI)
% ok 40		# conjf(-inf + infI)
% ok 41		# conj(-inf + infI)
% ok 42		# conjl(-inf + infI)
% Assertion failed: (creall(result) == ldexpl(14 * 0x1p-4, maxexp / 2)), function test_overflow, file test-csqrt.c, line 258.
% 1..15

Probably just due to not setting the rounding precision to extended
before calling the long double functions.  Callers are expected to
know about this bug, but the unreasonableness of this expectation is
demonstrated by not all of the tests doing it, and the ones that do
it do it incorrectly by setting it for all precisions, which breaks
some of the double precision functions in msun and may give false
successes by running the double or float precision functions in an
abnormal environment.

% ok 1 - csqrt
% ok 2 - csqrt
% ok 3 - csqrt
% ok 4 - csqrt
% ok 5 - csqrt
% ok 6 - csqrt
% ok 7 - csqrt
% ok 8 - csqrt
% ok 9 - csqrt
% ok 10 - csqrt
% ok 11 - csqrt
% ok 12 - csqrt
% ok 13 - csqrt
% ok 14 - csqrt
% Abort trap (core dumped)

The tests are missing fflush()'s, so the error output for test 15 (?) occurs
before the normal output for tests 1-14.  Then the shell prints the abort
message in the correct order.  Output to a terminal is more readable due
to the line buffering.

% Assertion failed: (fpequal((exp2)(_d), (__builtin_inff()))), function run_generic_tests, file test-exponential.c, line 118.
% 1..3
% Abort trap (core dumped)

Unordered again.  This is test 1 in test-exponential.  test-exponential does
set the rounding precision to extended.

% 1..8
% ok 1 - fenv
% ok 2 - fenv
% ok 3 - fenv
% ok 4 - fenv
% ok 5 - fenv
% ok 6 - fenv
% ok 7 - fenv
% ok 8 - fenv
% Assertion failed: (fpequal((fmal)((1.1897314953572317650E+4932L), (1.1897314953572317650E+4932L), (-__builtin_inff())), (-__builtin_inff()))), function test_infinities, file test-fma.c, line 156.

Maybe a general problem with __builting_inf() vs long doubles?

% 1..18
% ok 1 - fma zeroes
% ok 2 - fma zeroes
% ok 3 - fma zeroes
% ok 4 - fma zeroes
% Abort trap (core dumped)
% 1..12
% ok 1 - big = 1, small = 0
% ok 2 - big = 42, small = 41.999996185302734375
% ok 3 - big = 42.000003814697265625, small = 42
% ok 4 - big = -5, small = -5
% ok 5 - big = -3, small = -4
% ok 6 - big = 1, small = nan
% ok 7 - big = inf, small = nan
% ok 8 - big = inf, small = 1
% ok 9 - big = -3, small = -inf
% ok 10 - big = 3, small = -inf
% ok 11 - big = nan, small = nan
% ok 12 - big = 0, small = -0
% 1..3
% ok 1 - ilogb
% ok 2 - ilogbf
% ok 3 - ilogbl
% Assertion failed: (fpequal(acosf(_in), _out, ((0) * ldexpf(1.0, 1 - 24)))), function test_special, file test-invtrig.c, line 144.
% 1..7
% Abort trap (core dumped)

test-invtrig is missing setting of the rounding precision.

% Assertion failed: ((lrint)(__builtin_inff()) == (0) || fetestexcept(FE_INVALID)), function run_tests, file test-lrint.c, line 79.
% 1..1
% Abort trap (core dumped)

Same as on amd64.

This is compiler bug.  (lrint)(__builtin_inff()) is evaluated at compile
time despite being compiled with -O0, and it is evaluated incorrectly,
without setting FE_INVALID as lrint() is specified to do when the
result is not representable.  In other words, gcc doesn't understand its
own __builtin_inff() when combined with its builtin lrint().  Compiling
the tests with -fno-builtin "fixes" this by avoiding the buggy builtin
lrint().

The macros made debugging this painful.  I preprocessed the source file
using cpp -E and indent.  indent made a mess of the hex constants by
putting spaces in them.

% 1..1
% ok 1 - lround
% 1..1
% ok 1 - nan
% 1..5
% ok 1 - next
% ok 2 - next
% ok 3 - next
% ok 4 - next
% ok 5 - next
% 1..2
% ok 1 - rem
% ok 2 - rem
% 1..3
% ok 1 - trig
% ok 2 - trig
% ok 3 - trig

Bruce