This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Policy question -- libm-test: tests with sNaNs as inputs
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Wed, 3 Apr 2013 15:41:48 +0000
- Subject: Re: Policy question -- libm-test: tests with sNaNs as inputs
- References: <87ip43zl72 dot fsf at schwinge dot name>
On Wed, 3 Apr 2013, Thomas Schwinge wrote:
> I'd like to propose the following patch, which adds several tests with
> sNaNs as inputs to the libm-test framework.
The tests for hypot are wrong - there, qNaN is considered to represent
missing data, so hypot (qNaN, Inf) is Inf but hypot (sNaN, Inf) should be
qNaN plus exception. Implementing this for hypot, fmin, fmax or complex
functions would be a new feature rather than a simple bug fix, and I don't
think you should add any tests for those functions, or comments about such
tests being missing, unless you implement that new sNaN feature at the
same time.
> Now for the policy question: How to proceed in this case? Commit the
My practice is to keep the testsuite clean on at least x86 and x86_64, by
conditioning any new tests that fail on those architectures because of
known bugs with a #if condition with a comment referencing the bug number
(there are a few existing such comments in libm-test.inc). Other
architecture maintainers may then fix the bugs for their architecture or
add such conditionals in additional cases, depending on how difficult a
fix is.
--
Joseph S. Myers
joseph@codesourcery.com