[Cfp-interest] more on signaling NaN support

[Jim Thomas]

What support for signaling NaNs has our CFP specification required so far?

issignaling() type-generic macro
canonicalize() functions
SNANF, etc. macros
setpayloadsignaling() functions
getpayload functions (must not signal invalid if an input is a pointer 
to a signaling NaN)

We might want to add

isnan(), etc. type-generic classification macros must not signal invalid 
if an input is a signaling NaN
fabs(), copysign(), and negate must not signal invalid if an input is a 
signaling NaN

Is there more?

I've proposed adding:

----
Recommended practice: If the state of FENV_ACCESS is "on", then any 
operation with a signaling NaN input, unless explicitly specified 
otherwise, raises the "invalid" floating-point exception.

The macro

FE_SNANS_ALWAYS_INVALID

is defined if and only if the implementation follows the recommended 
practice above.

Any operation that raises an "invalid" floating-point exception, if 
delivering a floating type result, shall return a quiet NaN.
----

Only the last sentence is a requirement. The total requirements would 
still be minimal for implementations that don't want to invest in 
signaling NaN support.

It gives implementations that do want to support signaling NaNs in 
operations a simple rule. "Operations" here refers generally to 
functions as well as operators.

Of course, implementations might have their own compile options for 
signaling NaN support. The FE_SNANS_ALWAYS_INVALID macro gives the user 
a compile-time test for signaling NaN support in operations.

Even if FE_SNANS_ALWAYS_INVALID is not defined, the worst an operation 
can do with a signaling NaN input is to return a signaling NaN without a 
signal, which will likely lead to a signal later when a signaling NaN 
reaches a hardware FP instruction. A user can call canonicalize() to 
force a signal out of a signaling NaN.

-Jim