Are floatN_t in stdfloat guarenteed to be IEEE compliant?

Question

Unlike fundamental types – float, double and long double – are the new floatN_t types in <stdfloat> introduced in C++23 going to be always IEEE standard binary floating point types?

The cppreference page for fixed width floating-point does mention the bits of precision and exponent, which matches with IEEE standards. But that page doesn't explicitly mentions about IEEE standards anywhere. IEEE compliant floating points means, they not only should have same bits of precision and exponent, but the standard also lists many operations which have to be supported in a standard compliant way. So do these types strictly follow that?

Reclinate

Doesn't seem that way to me, according to the source you provide: "fixed width floating-point types must be aliases to extended floating point types (not float / double / long double)" – Heft

@Heft If at all floatN_t were aliases to float / double / long double, then you can say that floatN_t are not IEEE because these fundamental types are not guarenteed to be IEEE (although in practice most are). – Reclinate

Sourav Kannantha B, Even if IEEE standard binary floating point types and operations are specified, complete adherence to the IEEE is really hard. Be prepared for 99% compliance and not 100%. – Carlitacarlo

Sourav Kannantha B, Also complete adherence to the IEEE does not mean no variability in outcomes among implementations. IEEE allows for some variations in corner cases. So the question: why do you want IEEE compliance? What specific problem are you trying to solve? – Carlitacarlo

@chux-ReinstateMonica This was just a 'out-of-curious' question. I am not using stdfloat now. But just wanted to know to what extent it was compliant. Similar bit-count was just a coincidence or not? – Reclinate

Answer 1

Yes. The relevant section from the latest Draft for the C++23 Standard (cited below) makes explicit mention of the ISO/IEC/IEEE 60559 floating-point standard for the float*_t types. That is identical to the IEEE-754 standard according to Wikipedia:

The international standard ISO/IEC/IEEE 60559:2011 (with content identical to IEEE 754-2008) has been approved for adoption through ISO/IEC JTC 1/SC 25 under the ISO/IEEE PSDO Agreement and published.

Here is the first part of the relevant section from the Draft C++23 Standard (the definitions for other 'precision' types are similar):

6.8.3 Optional extended floating-point types    [basic.extended.fp]
¹    If the implementation supports an extended floating-point type ([basic.fundamental]) whose properties are specified by the ISO/IEC/IEEE 60559 floating-point interchange format binary16, then the typedef-name std​::​float16_­t is defined in the header <stdfloat> and names such a type, the macro __STDCPP_­FLOAT16_­T__ is defined ([cpp.predefined]), and the floating-point literal suffixes f16 and F16 are supported ([lex.fcon]).
…
(… And similarly for float32_t, float64_t, etc.)

Note: In terms of whether the cited paragraph demands that operations on such a type conform to the IEEE/ISO Standard, I would argue that it does. The "properties" of such variables includes their behaviour, and not just their representation format.

Circe

Does anything specify that the bits of floating-point values must be stored with the same endianness as those of integers, so that e.g. the sign bits of a float64_t and int64_t would be stored in the same place? – Broaden

Additionally, is there anything that would forbid an implementation from having float and double types that behave nothing like the IEEE-754 types, but then having a float64_t type which is represented in a manner compatible with IEEE-754, and is converted to the native float type whenever it is operated upon? – Broaden

@Broaden To the very best of my knowledge, any dependence on endianness is outside the purview of both the C++ and IEEE standards; that's an entirely different issue. – Circe

@Broaden On your second point: Categorically: "No!" (So long as the results of those operations are IEEE compliant.) – Circe

... the new std::float*_n types are distinct and separate types (even if they are equivalent). What the Standard dictates for one is not the same as what is required of the other. – Circe

On your first point, I should add, I think. It is an interesting point, that warrants further investigation (i.e. what are the "usual arithmetic conversions" when applied to native types mixed with the new standard types). – Circe

Does it say anywhere that if such types are not supported, neither typedef nor macro shall be defined? – Indignation

@Indignation Probably not. But absence of evidence is not evidence of absence: You can't expect the C++ Standard to express all the situations that do not conform. – Circe

@AdrianMole You can expect it to express how a conforming implementation should signal (absence of) support for optional parts, like IEEE 60559. – Indignation

@Indignation No. It expresses (quite clearly) that, if such macros/typedefs are defined, then conformance to the Standard is expected. How can you expect any Standard to express that something might conform? – Circe

"If and only if type conforming to xyz is supported, typedef x and macro y shall be defined." – Indignation

With respect, @Deduplicator, this whole, "if and only if" argument is way beyond the topic of this particular question/answer. If the relevant macro is defined, then you can expect the compiler to conform; if it is not defined, then you cannot expect that. – Circe

Answer 2

Yes, they are.

[stdfloat.syn] states that

The header defines type aliases for the optional extended floating-point types that are specified in [basic.extended.fp].

In turn, [basic.extended.fp] references types which are specified by ISO/IEC/IEEE 60559 floating-point interchange format

ISO/IEC/IEEE 60559 is the newer version of 754

Rugose