From: "Joseph S. Myers" <joseph@codesourcery.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: <libc-alpha@sourceware.org>, <libc-ports@sourceware.org>
Subject: Re: [PATCH] MIPS/glibc: soft-fp NaN representation corrections
Date: Wed, 24 Apr 2013 21:24:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1304242111460.20942@digraph.polyomino.org.uk> (raw)
In-Reply-To: <alpine.DEB.1.10.1304241815090.1453@tp.orcam.me.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
next prev parent reply other threads:[~2013-04-24 21:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 17:40 Maciej W. Rozycki
2013-04-24 21:24 ` Joseph S. Myers [this message]
2013-05-07 19:39 ` [BZ #15442][PATCH] " Maciej W. Rozycki
2013-05-13 23:19 ` [PING][BZ " Maciej W. Rozycki
2013-05-15 15:48 ` Joseph S. Myers
2013-05-15 15:54 ` Richard Henderson
2013-05-15 18:19 ` Andreas Jaeger
2013-05-16 22:56 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1304242111460.20942@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-ports@sourceware.org \
--cc=macro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).