On Tue, Sep 29, 2020 at 05:34:55PM +0100, Jonathan Wakely wrote:
> On Mon, 28 Sep 2020 at 23:15, Joseph Myers <jos...@codesourcery.com> wrote:
> >
> > On Mon, 28 Sep 2020, Michael Meissner via Gcc wrote:
> >
> > > > I'm not sure which patch in the series is supposed to be implementing
> > > > that, but C requires that long double and _Float128 are distinct types
> > > > (so
> > > > you can use _Generic to choose between them, for example) even if they
> > > > have the same ABI.
> > >
> > > Hmmm, but others said that it would complicate things if __float128 were
> > > different than long double. I've implemented it both ways (I would have
> > > to dig
> > > up the patches to have separate types).
> > >
> > > And doing so might break all of the glibc efforts to provide dual symbols.
> > >
> > > I could obviously use __float128 to be the same as long double, and
> > > _Float128
> > > being a unique type if long double is IEEE. And since C++ doesn't have
> > > _Float128, it would 'work' without introducing a new mangling name.
> >
> > My comment is specifically about _Float128, in C; it doesn't say anything
> > about what should happen for C++ (though it would be nice to resolve the
> > ICEs that occur when _FloatN / _FloatNx types leak into C++ code via
> > built-in functions, bug 85518). Maybe it makes sense for the type (or at
> > least the type used by the built-in functions and __float128, since
> > _Float128 itself can't be accessed directly in C++) to be the same in the
> > C++ case.
>
> I imagine C++ will want to support _Float128 at some point, with
> similar semantics to C.
>
> But if __float128 is the same type as __ieee128 (which is sometimes
> the same as long double), which is a different type to _Float128, then
> I think that will work for both C and C++.
>
> If the standards say we have a standard _Float128 type which is
> different to long double, that's fine. If the standard wants a
> different type, we'll support that. What I'd like to avoid is a
> non-standard __float128 type that is a different type to long double
> even if they use the same representation. That seems like a needless
> difference just for the sake of it.
As Segher says, I sometimes confuse 'types' with 'modes'.
I looked into this a bit, and I think we want to keep the current behavior (as
modified by the patches). As Joseph says, the _Float<n> types have their own
types, but may/may not use the same modes as other types. Obviously if these
types leak into C++ (i.e. but 85518), then something needs to be done about
mangling. But that is a machine independent issue, not a PowerPC issue.
Note, when I began the thread, I had talked about separating the types so that
internally we have 3 types (__float128, __ibm128, and long double), and in fact
I had made changes to that effect in a local sandbox. The discussion convinced
me that we probably don't want to go down this path.
I did play around with making _Float128 always use KFmode, but it will cause us
to need other changes. I can do these changes if needed, but it seems like a
lot of pointless work.
To summarize, the current state is:
1) If long double is IEEE 128-bit floating point.
_Float128 has its own type, and uses TFmode;
__float128/__ieee128 uses the long double type and uses TFmode;
__ibm128 uses its own type, and uses IFmode.
Mangling:
__float128 => "u9__ieee128"
__ibm128 => "g"
long double => "u9__ieee128"
2) If long double is IBM extended double:
_Float128 has its own type, and uses KFmode;
__float128/__ieee128 uses its own type, and uses KFmode.
__ibm128 uses the long double type and uses TFmode.
Mangling:
__float128 => "u9__ieee128"
__ibm128 => "g"
long double => "g"
3) If long double is 64-bits:
_Float128 has its own type, and uses KFmode;
__float128/__ieee128 uses its own type, and uses KFmode.
__ibm128 uses its own type and uses IFmode.
Mangling:
__float128 => "u9__ieee128"
__ibm128 => "g"
long double => "e"
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
