This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] MIPS/glibc: soft-fp NaN representation corrections
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Wed, 24 Apr 2013 21:24:13 +0000
- Subject: Re: [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>
On Wed, 24 Apr 2013, Maciej W. Rozycki 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.
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). 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.
The patch itself looks fine to me, but I think someone else should review
it as well.
--
Joseph S. Myers
joseph@codesourcery.com