Re: Potential upcoming changes in mangling to PowerPC GCC

Re: Potential upcoming changes in mangling to PowerPC GCC

[Michael Meissner]

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?

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: Potential upcoming changes in mangling to PowerPC GCC

[Jonathan Wakely]

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.

Re: Potential upcoming changes in mangling to PowerPC GCC

[Michael Meissner]

On Thu, Aug 04, 2022 at 10:14:10PM +0100, Jonathan Wakely wrote:
> 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.

I tend to agree that only having mangling for two 128-bit types (ieee and ibm),
no matter what they are called is better than trying to support 3 separate
types (explict ieee, explicit ibm, and whatever long double is).  That way we
don't have to come up with new mangling forms, which has backwards
compatibility issues.

But it is possible as distros move from having the default long double being
IBM to being IEEE, we will see disconnect in user code, where they want to use
long double and add an explicit __float128 type.

I imagine if x86 ever flips the switch so that -mlong-double-128 is default
(instead of -mlong-double-80), they would see the same issues between using
__float128 and long double.

And libstdc++ and glibc not using explicit long double is likely the best way
to avoid all of the issues.

There are still likely issues in moving from the current implementation, but it
is simpler if we don't have to have 4 different mangling forms (the explicit
forms, and the 2 forms for long double).

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com