Hi!
On Tue, Aug 16, 2022 at 08:07:48PM +0200, Jakub Jelinek wrote:
> On Thu, Aug 11, 2022 at 08:44:17PM +0000, Joseph Myers wrote:
> > On Thu, 11 Aug 2022, Michael Meissner via Gcc-patches wrote:
> > > In looking at it, I now believe that the type for _Float128 and __float128
> > > should always be the same within the compiler. Whether we would continue
> > > to
> > > use the same type for long double and _Float128/__float128 remains to be
> > > seen.
> >
> > long double and _Float128 must always be different types; that's how it's
> > defined in C23.
>
> And when we implement C++23 P1467R9, if std::float128_t will be
> _Float128 under the hood, then long double and _Float128 have to remain
> distinct types and mangle differently, long double (and __float128 if
> long double is IEEE quad and __float128 exists?) need to mangle the way
> they currently do and _Float128 should mangle as DF128_ .
> ::= DF <number> _ # ISO/IEC TS 18661 binary floating point type
> _FloatN (N bits)
So should we make std::floatNN_t be the same as _FloatNN, and mangled
as DF<NN>_ ? And __ieee128 (and long double implemented as that) the
same as we already have.
> Wonder how shall we mangle the underlying type of std::bfloat16_t though.
That should get some cross-platform mangling? Power shouldn't go its
own way here :-)
> I assume e.g. for libstdc++ implementation purposes we need to have
> __ibm128 and __float128 types mangling as long double mangles when the
> -mabi={ibm,ieee}longdouble option is used, because otherwise it would be
> really hard to implement it.
If at all possible it should be the same as we have already: otherwise
it will be at least five years before anything works again (for users).
This agrees with what you propose afaics, but let's make this explicit?
It helps us sleep at night :-)
Segher
