Re: IEEE Interchange floating point and extended floating point for C++

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Fri, 12 Mar 2021, 18:14 Joseph Myers, <joseph@codesourcery.com> wrote:

> On Fri, 12 Mar 2021, Joseph Myers wrote:
>
> > On Fri, 12 Mar 2021, Jonathan Wakely wrote:
> >
> > > On Fri, 12 Mar 2021 at 12:26, Sjoerd Meijer via Gcc <gcc@gcc.gnu.org>
> wrote:
> > > > So here's finally my concrete question: what do we think about
> making _Float16 available in C++ mode?
> > >
> > > I think GCC should do it.
> >
> > What about types with the same format as an existing type (but which are
> > nevertheless distinct types in C), such as _Float64 (typically same
> format
> > as double) or _Float32 (typically same format as float, but not promoted
> > when passed in variable arguments)?
>
> And also the _Float32x, _Float64x types (we don't have any targets
> supporting _Float128x).  (On all systems supporting those types in GCC,
> _Float32x has the same format as double and _Float64, and _Float64x has
> the same format as either long double or _Float128, but again they are
> different types.)
>

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.