On Thu, 4 Aug 2022 at 18:58, Michael Meissner via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Thu, Aug 04, 2022 at 10:49:24AM +0200, Nathan Sidwell wrote:
> > Not a problem. I don't think I have anything to add- I presume you've
> > thought about (weak) aliases to deal with the problematic changes you
> > mention towards the end?
>
> I've thought about it. I know in the past we had weak aliases to do the
> support the same way when we had the last name mangling change. I know those
> aliases weren't popular back then.
>
> Part of the reason for asking is I don't have a sense for how library
> maintainers use the __float128 and __ibm128 keywords. Do they treat them as
> full fledged types, or are they just convenient ways to compile code with both
> names rather than building two modules, with the different long double types?
Within libstdc++ it's not just a minor convenience, it's 100%
necessary to refer to both kinds (IEEE 128 and IBM 128) in the same
translation unit. There are C++ classes with member functions taking
both types, e.g.
struct Foo {
void f(__ibm128);
void f(__ieee128);
};
You can't do this by "building two modules" because it's a header and
you can't split the definition of a class across two different files.
And in many cases, it's a class template, so you can't even hide the
definition of the function in a .cc file, it has to be defined in the
header. So libstdc++ 100% requires a way to refer to "the type that is
long double" (which is easy, that's 'long double') and "the other
128-bit type that isn't long double" (which is one of __ibm128 or
__ieee128). So we need to refer to *at least* one of __ibm128 or
__ieee128, and in some cases it's simpler to not refer to 'long
double' at all (because its meaning can change) and just refer to
__ibm128 and __ieee128 because those always mean the same thing.
If the names or mangling for either of those types changes, it would
break libstdc++ and require more work just to restore the existing
functionality.
