[PATCH] Fix truncf for sNaN input

[Brian Inglis]

On 2020-03-17 09:26, Fabian Schriever wrote:
> 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:

Latest Volume 1. "Base Definitions" Chapter 4. "General Concepts" 4.21
"Treatment of NaN Arguments for the Mathematical Functions" available at:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_21

[free registration allows continuing access and downloads with minimal spam]

Unchanged:

> "On implementations that support the IEC 60559: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 IEC 60559:1989 standard 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-zero and the invalid floating-point exception shall
> be raised."

Section 4.20 "Treatment of Error Conditions for Mathematical Functions" may also
apply.

> 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.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.