Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jan 2012 03:12:14 -0500
From:      David Schultz <das@freebsd.org>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: fenv.h fixes for softfloat
Message-ID:  <20120114081214.GA14925@zim.MIT.EDU>
In-Reply-To: <1326509894.48691.100.camel@revolution.hippie.lan>
References:  <20120108183605.GA36775@zim.MIT.EDU> <1326144525.2199.32.camel@revolution.hippie.lan> <20120111052634.GA96534@zim.MIT.EDU> <20120111101833.GA88428@ci0.org> <1326291254.2419.55.camel@revolution.hippie.lan> <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 13, 2012, Ian Lepore wrote:
> These are the results of running all the regression tests (except those
> requiring complex number support) after applying the minor tweaks to
> David's original patches.  The build and run conditions are the same as
> I mentioned earlier in the thread.  

Thanks!  These are very helpful.  Some of the failures are due to
bugs that were fixed since 8.2-RELEASE.  (Indeed, the regression
tests were added because of the bugs.)  Other failures are more
mysterious.

> I looked into why test-lrint failed, and got as far as determing that
> the rint() routine is raising FE_INVALID when it executes either of the
> two "w = TWO52[sx]" expressions in the routine.  The path from there
> leads deep into places my innumeracy won't let me go.  
> 
> The other errors also look to be more related to numerical details of
> the implementation than to the changes in the environment support, and
> I'm really really not a math guy, so this seems like a good time to lob
> it back to someone who actually understands the code.

That's strange, because the test on line 81 uses 1.0 as the input.
For integral inputs, rint() shouldn't even be reaching those lines.
Are you sure it wasn't rintl() that failed?

> ---------- test-fma ----------
> 1..19
> ok 1 - fma zeroes
> ok 2 - fma zeroes
> ok 3 - fma zeroes
> ok 4 - fma zeroes
> ok 5 - fma infinities
> ok 6 - fma infinities
> ok 7 - fma infinities
> ok 8 - fma infinities
> ok 9 - fma NaNs
> ok 10 - fma small z
> ok 11 - fma small z
> ok 12 - fma small z
> ok 13 - fma small z
> ok 14 - fma big z
> ok 15 - fma big z
> ok 16 - fma big z
> ok 17 - fma big z
> ok 18 - fma accuracy
> Assertion failed: (fpequal((fmaf)((0x1.800002p+0), (0x1.800002p+0),
> (-0x1.000002p-46)), (0x1.200002p+1))), function test_double_rounding,
> file test-fma.c, line 456.
> Abort trap

No need to worry about this one.  It's fixed in r226371 and MFC'd
to 8-STABLE in r229840.

> ---------- test-fmaxmin ----------
> 1..12
> ok 1 - big = 0, small = 0
> ok 2 - big = 10, small = 9.999996185302734375
> ok 3 - big = 10.000003814697265625, small = 10
> ok 4 - big = -1, small = -1
> ok 5 - big = -1, small = -0
> fmaxl(0, nan) raised 0x1
> fmaxl(0, nan) = nan, expected 0
> fmaxl(nan, 0) raised 0x1
> fminl(0, nan) raised 0x1
> fminl(0, nan) = nan, expected 0
> fminl(nan, 0) raised 0x1
> FAILURE in rounding mode 0
> not ok 6 - big = 0, small = nan
> fmaxl(inf, nan) raised 0x1
> fmaxl(inf, nan) = nan, expected inf
> fmaxl(nan, inf) raised 0x1
> fminl(inf, nan) raised 0x1
> fminl(inf, nan) = nan, expected inf
> fminl(nan, inf) raised 0x1
> FAILURE in rounding mode 0
> not ok 7 - big = inf, small = nan
> ok 8 - big = inf, small = 0
> ok 9 - big = -1, small = -inf
> ok 10 - big = 1, small = -inf
> fmaxl(nan, nan) raised 0x1
> fmaxl(nan, nan) raised 0x1
> fminl(nan, nan) raised 0x1
> fminl(nan, nan) raised 0x1
> FAILURE in rounding mode 0
> not ok 11 - big = nan, small = nan
> ok 12 - big = 0, small = -0

The interesting thing about these failures is that the reported
inputs to the tests are wrong.  I suggest running the tests in
tools/regression/lib/libc/stdio, particularly test-printfloat.

> ---------- test-ilogb ----------
> 1..3
> ok 1 - ilogb
> ok 2 - ilogbf
> Assertion failed: (i == e), function main, file test-ilogb.c, line 80.
> Abort trap

Likely related to the previous errors.  I'm wondering if the
definitions in libc/arm/_fpmath.h get the endianness right
for the ARM chip you're using.

> ---------- test-lrint ----------
> 1..1
> Assertion failed: (fetestexcept(FE_ALL_EXCEPT) == (0)), function
> run_tests, file test-lrint.c, line 81.
> Abort trap
> ---------- test-lround ----------
> 1..1
> Assertion failed: (fetestexcept(FE_ALL_EXCEPT) == (0)), function main,
> file test-lround.c, line 74.
> Abort trap

As mentioned above, it's hard to say what's causing these failures
if fenv and softfloat work.

> ---------- test-nearbyint ----------
> 1..12
> ok 1		# nearbyint(+-0)
> ok 2		# modf(+-0)
> ok 3		# nearbyint(+-0.5)
> ok 4		# modf(+-0.5)
> ok 5		# nearbyint(+-3.14159)
> ok 6		# modf(+-3.14159)
> ok 7		# nearbyint(+-65536.5)
> ok 8		# modf(+-65536.5)
> ok 9		# nearbyint(+-inf)
> Assertion failed: (fpequal(out, modf(in, &ipart))), function test_modf,
> file test-nearbyint.c, line 147.
> Abort trap

Minor bug, fixed in r226606.

> ---------- test-next ----------
> 1..5
> ok 1 - next
> ok 2 - next
> ok 3 - next
> ok 4 - next
> 216: idd(nexttoward(INFINITY, DBL_MAX * 2.0L)) returned inf, expecting
> 0x1.fffffffffffffp+1023
> Abort trap

This was a bug in the test, which didn't know how to cope with
architectures where long double doesn't have more range than
double.  The test is fixed in 230102.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120114081214.GA14925>