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.
