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. The existing code in build_common_tree_nodes that creates all the _FloatN / _FloatNx type nodes always creates a new node with make_node. And since I didn't spot anything in your patch series that changes that, I couldn't see how that patch series actually does make them the same type. -- Joseph S. Myers jos...@codesourcery.com
