IEEE Interchange floating point and extended floating point for C++
Mon Mar 15 10:16:56 GMT 2021
Many thanks for your replies and thoughts on this.
I wanted to add that I agree with this, and say that this is the
current state in Clang (exactly because of the reason that
_Float16 is entirely new):
I see less value in adding additional distinct types that don't add anything you can't already do. _Float16 gives you access to an entirely new data type. _Float32 just complicates overloading of it's a new type with the same representation as an existing one. With the proposed std::float32 typedef for C++ users will still be able to write code that definitely uses an IEEE binary32 type without needing a new type to be introduced. ISTM that what users really want is "a type guaranteed to be IEEE binary32" and whether that is float or _Float32 is mostly irrelevant.
And isn't the good news that this is all fairly orthogonal
and a start could be made with _Float16 and others could be
added later if required?
From: Jonathan Wakely <email@example.com>
Sent: 12 March 2021 22:03
To: Joseph Myers <firstname.lastname@example.org>
Cc: Sjoerd Meijer <Sjoerd.Meijer@arm.com>; Kito Cheng <email@example.com>; GCC <firstname.lastname@example.org>
Subject: Re: IEEE Interchange floating point and extended floating point for C++
On Fri, 12 Mar 2021, 21:55 Joseph Myers, <email@example.com<mailto:firstname.lastname@example.org>> wrote:
On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:
> I see less value in adding additional distinct types that don't add
> anything you can't already do. _Float16 gives you access to an entirely new
> data type. _Float32 just complicates overloading of it's a new type with
So would you then support _Float128, and the corresponding f128/F128
literal suffixes, in C++, as a "more standard" version of __float128, in
the case where it has a different format from long double (e.g. x86_64)
but not when it has the same format as long double?
Or support it in both cases, but for the latter case as an alias for long double rather than as a distinct type.
I can ask the WG21 Numerics study group what they think makes sense for C++, because I'm not certain my choices are the right ones.
More information about the Gcc