On 17/09/2021 09.40, Matthias Kretz wrote:
> On Thursday, 16 September 2021 23:42:56 CEST Jens Maurer wrote:
>> On 16/09/2021 23.00, Matthias Kretz via Liaison wrote:

>>> I believe
>>> std::floatN_t and _FloatN need to be distinct types anyway. P1467R4 says
>>> "The proposed usual arithmetic conversions when mixing different
>>> floating-point types are>
>>> essentially the same in both languages". But I read it differently:
>>> float + _Float32 -> _Float32
>>> float + std::float32 -> float.
>>
>> Not good.
>>
>> Remarkably, the result for "double" seems to be the other way round under
>> N2601:
>>
>> double + _Float64 = double
>>
>> per section X.4.2 (page 10 line 17).
>
> No, line 11 should take precedence. _Float64 is an interchange floating type,
> so "the other operand is converted, without change of type domain, to a type
> whose corresponding real type is that same interchange floating type".

Ok, at least that's internally consistent.

So, P1467R4 prefers standard floating-point types over extended ones
in the conversions (similar to what we do with integer types),
but WG14 N2601 prefers the new-style floating-point types
(assuming same set of values, of course).

Regrettably, for integers, both C and C++ prefer the standard
integer types over the extended ones, so

  int + (hypothetical _Int32) = int

We should ask the C floating-point group why they deviated from that
precedent.
And the author of P1467 should update his paper to make it say the
right thing.

>>> Would it be an option to keep _Float32 and std::float32 distinct types?
>>
>> That seems unhelpful. If those types have the same properties
>> (i.e. represent IEEE interchange types), they should be the
>> same from a type system perspective.
>
> Do I read X.6 [2] correctly that all _Float* types must fully support NaN and
> Inf?

Sounds like it. I also notice that Annex X seems to assume that
"double" is at least 64-bits:

"The default argument promotions (6.5.2.2) for functions whose type does
not include a prototype are expanded so that arguments that have type _Float16,
_Float32, or _Float64 are promoted to double."

(assuming they care about avoiding lossy promotions).

> Whereas P1467 intends to leave NaN and Inf support implementation-
> defined? Consequently, a feature like -ffinite-math-only would have to disable
> Annex X support in the compiler / only apply to "standard floating types"?

Seems like it.

> C and C++ may be defining the same types in terms of binary representation.
> But the C and C++ committees might have different semantics in mind. If I
> understand the C specification correctly, we should probably have a dedicated
> meeting about floating-point semantics where we invite the C FP group ...

At the very least, it seems to me that we need a clearer picture of what
exactly P1467 will gives us in C++.
(It seems the plethora of additional overloads of math functions isn't
covered.)

Jens