[Cfp-interest] more on signaling NaNs

[Thomas, James]

Jon and I got an action item at the Aug CFP meeting to investigate the signaling NaN behavior in cases of functions specified to return a non-NaN result for NaN inputs, e.g., hypot(inf, NaN) = Inf. In looking into this, we saw that C1x, plus our changes so far, appear to prohibit support for signaling NaNs - though in a fixable way. The proposed changes below are intended to allow (but not require) support for signaling NaNs as specified in IEEE 754-2008, and to provide optional specification implementations might follow to more fully support signaling NaNs. Also, the resulting specification addresses the cases of functions specified to return a non-NaN result for NaN inputs.

7.3.9.5: change NaN to "quiet NaN"

footnote 237: change NaN to "quiet NaN" twice

footnote 238: change NaN to "quiet NaN"

7.12.14: change from 4th sentence beginning "The following ..." to "The following subclauses provide macros that are quiet versions of the relational operators: the macros do not raise the "invalid" 
floating-point exception as an effect of quiet NaN arguments. The comparison macros facilitate writing efficient code that accounts for quiet NaNs without ..."

7.12.14.1-5: append to "when x and y are unordered" the phrase "and neither is a signaling NaN"

7.12.14.6: append to the Description "The unordered macro raises no floating-point exceptions if neither argument is a signaling NaN."

F.2.1 replace with
-----
The NAN and INFINITY macros and the nan functions in <math.h> provide designations for IEC 60559 quiet NaNs and infinities. The signaling NaN macros, SNANF, etc., in <math.h> provide designations for IEC 60559 signaling NaNs.

This annex does not require the full support for signaling NaNs specified in IEC 60559. This annex uses the term NaN, unless explicitly qualified, to denote quiet NaNs. Where specification of signaling NaNs is not provided, the behavior of signaling NaNs is undefined.

Any operator or <math.h> function that raises an "invalid" 
floating-point exception, if delivering a floating type result, shall return a quiet NaN.

In order to support signaling NaNs as specified in IEC 60559, an implementation should adhere to the following recommended practice.

Recommended practice: Any floating-point operator or <math.h> function with a signaling NaN input, unless explicitly specified otherwise, raises an invalid floating-point exception.

Note: Some functions do not propagate quiet NaN arguments. For example, hypot(x, y) returns infinity if x or y is infinite and the other is a quiet NaN. The recommended practice in this subclause specifies that these functions (and others) raise the "invalid" floating-point exception if an argument is a signaling NaN, which also implies they return a quiet NaN in these cases.

The <fenv.h> header defines the macro

FE_SNANS_ALWAYS_SIGNAL

if and only if the implements follows the recommended practice above.
-----

F.9.2 bullet 1*x and x/1 -> x: replace "are equivalent" with "may be regarded as equivalent" (retain footnote)


The following changes in Annex G to are intended to clarify that Annex 
does not include specification for signaling NaNs:

G.3 #1: change NaN to "quiet NaN"

G.6 #4: append "In subsequent subclauses in G.6 "NaN" refers to a quiet 
NaN. Annex G does not define the behavior of signaling NaNs.

Footnote 359: change NaN to "quiet NaN"


The following are 3 cleanup items for the NaNs proposal, unrelated to 
the issues above:

Canonicalize isn't defined for non 754-2008 implementations. We need to 
define it or move the function to Annex F.

Payload isn't defined for non 754-2008 implementations. We need to 
define it or move the payload functions to Annex F.

Replace SNAND with SNAN?

-Jim