[PATCH] Fix truncf for sNaN input

[Keith Packard]

Joseph Myers <joseph@codesourcery.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20200316/4bdc7499/attachment.sig>