[conv] Floating-point conversions should not require signaling NaN to be preserved

[eisenwave]

Section: [conv]

Issue description

Floating-point promotion ([conv.fpprom]) and floating-point conversion ([conv.double]) require that a value is unchanged if possible.

No compiler fully implements this wording because for a conversion from float to double, they emit a cvtss2sd instruction, which converts signaling NaNs to quiet NaNs. This implements the convertFormat operation as specified in ISO/IEC 60559:2020 §5.4.2.

Proposed resolution

Change [conv.fpprom] paragraph 1 as follows:

 A prvalue of type float can be converted to a prvalue of type double.
 The value is unchanged
+, except that a signaling NaN may be converted to a quiet NaN
 .

Change [conv.double] paragraph 2 as follows:

 If the source value can be exactly represented in the destination type,
 the result of the conversion is that exact representation
+, except that a signaling NaN may be converted to a quiet NaN
 .
 If the source value is between two adjacent destination values,
 the result of the conversion is an implementation-defined choice of either of those values. 
 Otherwise, the behavior is undefined.

Important

UPDATE: I now believe that there is no defect specifically in this area, if we make it clear that qNaN and sNaN are the same value in P3938R1.

I've had a chat with the Floating-Point Study Group; the C wording is almost identical to that of C++ here, which can give us guidance. The corresponding C wording seems to work because quiet and signaling NaN are not distinct values. Consider Table 3.1 from ISO/IEC 60559:

When C talks about a "value", this is talking about specification level 2; anything below that deals with the representation of the same value. Notably, the C standard says in §5.3.5.3.3:

A NaN is a value signifying Not-a-Number. A quiet NaN propagates through almost every arithmetic
operation without raising a floating-point exception; a signaling NaN generally raises a floating-point exception when occurring as an arithmetic operand.

It looks like "NaN" is the only thing defined as a value, and whether that value is quiet or signaling is an additional property. We don't have any C++ wording that clarifies that, but if we did, [conv] would work fine.

[safocl]

I believe the standard's provisions assume that, according to [basic.fundamental#12], set of values of the type float is a subset of the set of values of the type double, as well as [basic.fundamental#13].
In my opinion, NANs don't appear to be included in this set of values, but rather merely represent a special state defined by the implementation.

[basic.fundamental#13]

13 The minimum range of representable values for a floating-point type is the most negative finite floating-point number representable in that type through the most positive finite floating-point number representable in that type.
In addition, if negative infinity is representable in a type, the range of that type is extended to all negative real numbers; likewise, if positive infinity is representable in a type, the range of that type is extended to all positive real numbers.

[eisenwave]

I don't see how "range of representable" values is relevant here in this case. The paragraphs I'm pointing out don't reference this term at all; they talk about exact preservation of value, and qNaN and sNaN are values (in the C++ sense, albeit not in the mathematical sense).

If they were not values, the defect would be tremendously greater because we would have no wording that states that numeric_limits<float>::quiet_NaN() produces qNaN when converted to double; it would just be a wording hole. I don't think that's the case though.

[safocl]

they talk about exact preservation of value

I think that in this case the values ​​implied are exactly those specified in [basic.fundamental#12] and [basic.fundamental#13], and these values ​​cannot change depending on whether the {s,q}NANs states are enabled or disabled. However, the implementation may behave specially in the presence of such states ({s,q}NANs).

[safocl]

In my opinion, NAN does not refer to the value itself, but to the state of the calculation and informing the implementation (system).

[eisenwave]

"Value" is formally defined in https://eel.is/c++draft/basic.types.general#def:value for trivially copyable types as being "one discrete element of an implementation-defined set of values". It is also stated to be determined by the value representation, which NaNs and infinities obviously are. "Range of representable values" is an entirely separate term which is used in a number of places, and is not a definition of "value".

The standard is not very clear when it comes to distinguishing "mathematical value" from "C++ value", but in this case, there is nothing to suggest that infinities or NaNs are not handled by [conf.fpprom], and if they aren't, we have a major wording hole anyway.

[safocl]

std::has_unique_object_representations_v<float> may be false depending on the implementation (presumably due to the presence of NAN service flags in the representation). It's also believed that such service flags may not be preserved when copying floating-point number objects (which may also serve as an indirect justification for the fact that NAN is not part of the value). It's also believed that service flags such as NAN may not be included in the storage occupied by floating-point numbers at all.

static_assert(std::has_unique_object_representations_v<float>); // may be fail

https://godbolt.org/z/Tn3qWczqK

In my opinion, this may not be described by the C++ Standard and may go beyond its scope.

[eisenwave]

std::has_unique_object_representations_v<float> is false because the single value "quiet NaN" has a variety of different object representations (qNaNs that differ only in sign bit and payload).

It's also believed that service flags such as NAN may not be included in the storage occupied by floating-point numbers at all.

No idea where you're getting that from, but that would not be a compliant implementation because float is trivially copyable, so copying the bytes of a quiet NaN into another float also has to be qNaN. NaN is not a "service flag", and I'm not aware of any floating-point implementation where NaN is represented using a separate CPU flag rather than the bits in the register and in memory, or whatever you mean by "service flag".

In my opinion, this may not be described by the C++ Standard and may go beyond its scope.

No, the value of has_unique_object_representations<float> is consistent with how the trait is defined in the standard.

[safocl]

No, the value of has_unique_object_representations<float> is consistent with how the trait is defined in the standard.

oh, i meant in the context of the rules [conv.fpprom]/p1 and [conv.double]/p2 when asking whether they should contain definitions regarding NAN (not about the case involving std::has_unique_object_representations_v<float>)

In other words, I wanted to express that, in my opinion, the implementation can still legitimately do "except that a signaling NaN may be converted to a quiet NaN"

[eisenwave]

See the update in the top message. I think this issue could be NAD once we clarify what constitutes a "value".