From: "Keith Packard" <keithp@keithp.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Kito Cheng <kito.cheng@gmail.com>, Newlib <newlib@sourceware.org>
Subject: Re: [PATCH 0/2] libm/riscv: Fixing machine-specific fma/sqrt
Date: Mon, 07 Sep 2020 15:52:53 -0700 [thread overview]
Message-ID: <87eend42t6.fsf@keithp.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2009071736590.18581@digraph.polyomino.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]
Joseph Myers <joseph@codesourcery.com> writes:
> However, it's probably nontrivial to get the tests running on other
> implementations, since they freely make use of glibc-specific
> features, and the particular glibc choices they test for regarding
> errno, exceptions and expected accuracy of results may not match the
> choices made by other libm implementations.
I agree -- I looked at getting the glibc tests running on newlib and
decided that it would be more effort that I could afford. For now, I've
got the original newlib test suite running after spending several months
fixing it.
In particular, for the math tests, I ran glibc against the test vectors
and replaced the expected results with those as the existing values had
become corrupted over the years (not just inaccurate, but wildly
wrong). Mismatches between newlib and glibc were investigated, and
patches to newlib have been integrated. No patches were needed for
glibc. Now newlib generates results that match glibc within reasonable
tolerance bounds. With the recent patches to fix up exceptions and errno
values, newlib and glibc match there as well. I guess this is kinda like
testing newlib against the glibc test suite at a distance -- glibc gets
tested, then we make sure newlib and glibc generate the same values for
a different set of tests...
I'd love to be able to spend time improving the accuracy of newlib code,
but just having code which constantly measures 'reasonably close' to
glibc is a huge improvement from my perspective.
--
-keith
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-09-07 22:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 20:54 Keith Packard
2020-09-03 20:54 ` [PATCH 1/2] libm/riscv: Fix machine-specific sqrt build process Keith Packard
2020-09-03 20:54 ` [PATCH 2/2] libm/riscv: Use common fma code when necessary Keith Packard
2020-09-04 3:07 ` [PATCH 0/2] libm/riscv: Fixing machine-specific fma/sqrt Kito Cheng
2020-09-04 4:51 ` Keith Packard
2020-09-07 17:41 ` Joseph Myers
2020-09-07 22:52 ` Keith Packard [this message]
2020-09-04 13:11 ` Corinna Vinschen
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=87eend42t6.fsf@keithp.com \
--to=keithp@keithp.com \
--cc=joseph@codesourcery.com \
--cc=kito.cheng@gmail.com \
--cc=newlib@sourceware.org \
/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).