[PATCH] Fix truncf for sNaN input

[Fabian Schriever]

Am 17/03/2020 um 02:30 schrieb Joseph Myers:
> On Mon, 16 Mar 2020, Keith Packard via Newlib wrote:
>
>> 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 don't think POSIX specifications should be trusted for how functions
> should behave with sNaN inputs.  Rather, prefer the specifications from TS
> 18661-1 (or the latest C2x draft which has TS 18661-1 integrated).
>
I agree that both the IEEE-754 and C standards should take precedence 
over POSIX, nonetheless POSIX does contain a chapter on the treatment of 
NaNs including signaling NaNs: §4.20 (I only have access to the POSIX 
draft 3 from 2007: http://www.open-std.org/jtc1/sc22/open/n4217.pdf). It 
contains the following:

On implementations that support the IEC60559: 1989 standard floating 
point, functions with signaling NaN argument(s) shall be treated as if 
the function were called with an argument that is a required domain 
error and shall return a quiet NaN result, except where stated otherwise.
Note:    The function might never see the signaling NaN, since it might 
trigger when the arguments are evaluated during the function call.
On implementations that support the IEC60559: 1989standard floating 
point, for those functions that do not have a documented domain error, 
the following shall apply:
     These functions shall fail if:
     Domain Error   Any argument is a signaling NaN.
     Either, the integer expression (math_errhandling & MATH_ERRNO) is 
non-zero and errno shall be set to [EDOM], or the integer expression 
(math_errhandling &MATH_ERREXCEPT) is non-zeroand the invalid 
floating-point exception shall be raised.

For this change I only sought to have the single-precision function 
perform the same as it's double counterpart for now. I have not checked 
whether the POSIX requirements regarding errno are met.