[PATCH] Fix truncf for sNaN input

[Joseph Myers]

On Wed, 11 Mar 2020, Keith Packard via Newlib wrote:

> Joseph Myers <joseph@codesourcery.com> writes:
> 
> > That manpage is wrong.  The underlying IEEE operation should raise 
> > "invalid" and return a qNaN for an sNaN operand (but never raises 
> > "inexact").
> 
> Hrm. IEEE 754 says that you only get "invalid" if the NaN or infinite
> operand cannot be represented in the destination format. As these
> functions return the same type as their operand, NaN and inf values can
> be represented in the return value.
> 
> Are you referring to some other standard?

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

> Also, glibc works the way the manual says, and I'd really like newlib
> and glibc to have the same general behavior, even if newlib isn't quite
> as accurate as glibc for some operations.

glibc's libm-test-trunc.inc explicitly verifies that sNaN inputs to trunc 
functions result in a qNaN output with "invalid" but not "inexact" raised.

-- 
Joseph S. Myers
joseph@codesourcery.com