This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [BZ #15442][PATCH] MIPS/glibc: soft-fp NaN representation corrections
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Tue, 7 May 2013 20:39:07 +0100
- Subject: Re: [BZ #15442][PATCH] MIPS/glibc: soft-fp NaN representation corrections
- References: <alpine dot DEB dot 1 dot 10 dot 1304241815090 dot 1453 at tp dot orcam dot me dot uk> <Pine dot LNX dot 4 dot 64 dot 1304242111460 dot 20942 at digraph dot polyomino dot org dot uk>
On Wed, 24 Apr 2013, Joseph S. Myers wrote:
> > These changes touch generic code, for the most part. They are supposed
> > not to affect targets other than MIPS, however I think it would make sense
> > to test them at least on a selection of other targets glibc supports.
> > However I am not familiar enough with other targets to know how much
> > soft-fp is used across them; also I think automatic testing may have a
> > better value than manually poking at a function or three. I will
> > therefore appreciate ideas as to how to test these changes, or any other
> > help with that indeed.
>
> I have run powerpc-nofpu testing with this patch applied and not seen any
> NaN-related failures, and also confirmed that the generated libc/libm
> binaries are unchanged by the patch.
Thanks.
> I would note that the test results would be better indicative of working
> NaN handling if Thomas's patch
> <http://sourceware.org/ml/libc-ports/2013-04/msg00008.html> to test sNaN
> inputs were checked in (minus the parts that as I noted were incorrect,
> and with appropriate conditionals, with comments referencing filed bugs,
> for cases that don't yet pass) - which it doesn't seem to be yet.
>
> I believe this patch should fix at least one user-visible bug regarding
> sqrtl NaN handling (handling of input NaNs, and producing the correct sort
> of NaN as output for negative input) - and this should show up as an
> improvement on the test-ldouble results (although there will still be
> plenty of failures there arising from use of fp-bit in libgcc not
> supporting exceptions / rounding modes).
These changes indeed cause the following progressions for New-ABI MIPS
targets, thanks for the hint:
--- test-ldouble.out 2013-05-02 02:36:49.138155826 +0100
+++ test-ldouble.out 2013-05-03 20:01:50.576925141 +0100
@@ -382,11 +382,6 @@
Failure: pow (-min_value, 0x1.ffffffffffffffffffffffffffffp+113) == +0:
Exception "Underflow" not set
Failure: pow (-min_value, max_value) == +0: Exception "Underflow" not set
Failure: pow (2.0, -100000.0) == +0: Exception "Underflow" not set
-Failure: sqrt (qNaN) == qNaN: Exception "Invalid operation" set
-Failure: Test: sqrt (qNaN) == qNaN
-Result:
- is: sNaN
- should be: qNaN
Failure: Test: sqrt (-1) == qNaN
Result:
is: sNaN
@@ -10028,4 +10023,4 @@
Test suite completed:
11156 test cases plus 10128 tests for exception flags executed.
- 1986 errors occurred.
+ 1984 errors occurred.
-- no progressions are seen for negative inputs because for those the
result is passed from __kernel_standard (-lieee is not used by the test
suite for some reason that I don't know; I think for the best results at
least IEEE error handling should be tested in addition to the default of
POSIX.1) that returns a double value and therefore has to be extended to a
long double value with the aid of fp-bit that in turn has a bug in this
area too (discussed here:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00278.html).
> If that bug isn't already in Bugzilla, it should be filed there. In any
> case, the appropriate [BZ #N] notation should be used in the ChangeLog
> entries (toplevel ChangeLog, and ports/ChangeLog.mips, not necessarily
> other ports/ChangeLog.<arch> files although it's harmless to include it
> there as well) to point to the bug, which should also be added to the
> list of fixed bugs in NEWS as part of the fixing commit.
I haven't found anything relevant, so this is now BZ #15442.
> The patch itself looks fine to me, but I think someone else should review
> it as well.
I will appreciate that too -- ping?
Maciej