Date: Mon, 15 Nov 2010 13:39:47 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alexander Best <arundel@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu>, Ulrich Spoerlein <uqs@freebsd.org> Subject: Re: svn commit: r215237 - head/lib/msun/src Message-ID: <20101115124817.O1683@besplex.bde.org> In-Reply-To: <20101115005123.GA46134@freebsd.org> References: <201011131054.oADAsA7I045096@svn.freebsd.org> <20101113125648.GA25183@freebsd.org> <20101113164645.GB69612@troutmask.apl.washington.edu> <20101115005123.GA46134@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101115124817.O1683>