Potential upcoming changes in mangling to PowerPC GCC

Jonathan Wakely jwakely.gcc@gmail.com
Thu Aug 4 21:14:10 GMT 2022


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.


More information about the Libc-alpha mailing list