From owner-freebsd-arm@FreeBSD.ORG Sat Jan 14 08:12:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224C11065673 for ; Sat, 14 Jan 2012 08:12:17 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id EE1808FC12 for ; Sat, 14 Jan 2012 08:12:16 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id q0E8CE1O015423; Sat, 14 Jan 2012 03:12:14 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id q0E8CERp015422; Sat, 14 Jan 2012 03:12:14 -0500 (EST) (envelope-from das@freebsd.org) Date: Sat, 14 Jan 2012 03:12:14 -0500 From: David Schultz To: Ian Lepore Message-ID: <20120114081214.GA14925@zim.MIT.EDU> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326509894.48691.100.camel@revolution.hippie.lan> Cc: freebsd-arm@freebsd.org Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 08:12:17 -0000 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.