Re: [PATCH] Fix truncf for sNaN input

Keith Packard via Newlib <[email protected]> Mon, 16 Mar 2020 12:50:54 -0700

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

Joseph Myers <[email protected]> writes:

> I'm referring to 6.2 Operations with NaNs, "Signaling NaNs shall be 
> reserved operands that signal the invalid operation exception (see 7.2) 
> for every general-computational and signaling-computational operation 
> except for the conversions described in 5.12.".

I believe you are concerned with the exception behavior, where the
original code was wrong. Section 5.9 says that conversion functions
signal for sNaN input, while 6.2 says that they deliver a qNaN result.

I was concerned with what NaN values are delivered from a NaN
operand, given the POSIX specification which says that the operand
itself shall be delivered if it is a NaN.

I hadn't considered the exception behavior, nor had I realized that sNaN
operands cause a qNaN to be delivered.

I need to interpret the POSIX spec as saying that a NaN operand will
deliver *some* NaN, but not that it will deliver the NaN operand. The
functions cannot do this in the case of sNaN operands which must deliver
a qNaN according to the IEEE spec.

I'll update the newlib tests to verify that sNaN parameters deliver qNaN
results, and to allow any qNaN value for a qNaN operand, instead of
requiring that the functions return precisely the same qNaN value. Those
tests don't currently encode the signal behavior; I'll have to add
support for that at some point.

Thanks much for your clarifications and pointers to the relevant specs.

-- 
-keith

signature.asc (application/pgp-signature, 832 B)