Potential upcoming changes in mangling to PowerPC GCC

Potential upcoming changes in mangling to PowerPC GCC

[Michael Meissner]

Note, I tried to send this out before, but it didn't seem to go out.  Sorry if
you got it twice.

Sorry for the scatter shot mail that covers C++, Objective C++, Glibc,
etc. developers, but I wanted to discuss and get buy-in on changes to the
PowerPC GCC compiler that I would like to do in the endless project of
supporting IEEE 128-bit floating point.  Sorry if I spammed your inbox if this
doesn't concern you.

At the moment, GCC 12 on the server PowerPC systems supports multiple 128-bit
floating point types:

    *	_Float128 (in the C language): IEEE 128-bit floating point;

    *	__float128 (in the C and C++ languages): IEEE 128-bit floating point;

    *	long double: One of IEEE 128-bit floating, IBM 128-bit floating point,
	or 64-bit floating point; (and)

    *	__ibm128: Explicit IBM 128-bit floating point.

And there are 3 modes:

    *	KFmode: IEEE 128-bit floating point;
    *	IFmode: IBM 128-bit floating point; (and)
    *	TFmode: Either IEEE 128-bit or IBM 128-bit floating point.

But internally within the compiler there are mostly only two separate types, an
IEEE 128-bit and IBM 128-bit floating point.

If a file is compiled when long double uses the IEEE 128-bit floating point
type, then the __float128 type is the long double type and it uses the TFmode
mode.  And while the _Float128 type is distinct from long double, it also uses
TFmode.  The __ibm128 type is distinct, and it uses IFmode.

If a file is compiled when long double uses IBM 128-bit floating point, then
the __float128 type uses the _Float128 type, and both types use KFmode.  The
__ibm128 type uses the long double type, and both types use TFmode.

While things mostly work with this setup, there are some things that don't work
as well.  For example, 3 of the tests fail when you are using a system like
Fedora 36 where IEEE 128-bit long double is default.  These 3 tests use the
'nanqs' built-in function, which is mapped to 'nanf128s' and it delivers a
_Float128 signaling NaN.  But since __float128 uses a different type, the
signaling NaN is converted and it loses the signaling property.  The tests that
fail are:

    *	gcc.dg/torture/float128-nan.c
    *	gcc.target/powerpc/nan128-1.c
    *	gcc.target/powerpc/pr105334.c

In addition, it would be nice if we could refine the setting of bits in the ELF
header so that if you pass an explicit __float128 or __ibm128 object, it
doesn't set the bits that you used long double of the appropriate type.  But
the code that sets these bits is done in the RTL stages, and it only looks at
modes, not at types.

Now, I'm working on patches to 'do the right thing':

    *	Make _Float128 and __float128 always use the same distinct type and
	always use KFmode;

    *	Make __ibm128 use a distinct type and always use IFmode; (and)

    *	Long double would not share an internal type with either _Float128,
	__float128, or __ibm128.  It would always use TFmode.

One of the issues that comes up is the mangling support.  I wanted to get
buy-in on the solutions from the affected users:

Because long double mangles the same as either __float128 or __ibm128, you
cannot write programs like:

	double convert (__ibm128    x) { return x; }
	double convert (__float128  x) { return x; }
	double convert (long double x) { return x; }

You would have to write on a system with long double being IBM 128-bit:

	double convert (__float128  x) { return x; }
	double convert (long double x) { return x; }

or on a system with long double being IEEE 128-bit:

	double convert (__ibm128    x) { return x; }
	double convert (long double x) { return x; }

At the moment, the mangling rules are:

    *	If the type uses the IBM 128-bit encoding, use "g" for mangling;

    *	If the type uses the IEEE 128-bit encoding, use "u9__ieee128" for
	mangling.

I would suggest at least adding the rule:

    *	If the type is explicitly __ibm128, use "u8__ibm128" for the mangling,
	and if it is long double that uses the IBM 128-bit encoding, continue
	to use "g" for the mangling.  This shows up in the test suite
	g++.target/powerpc/pr85657.C.

We probably should think about the reverse case of separating explict
__float128 from long double that happens to use the IEEE 128-bit encoding.  I
suspect the right solution is to change the mangling on __float128 and leave
long double alone.  If so, any ideas on the mangling we should use?  Perhaps we
should use "DF128" which is the mangling for ISO/IEC TS 18661 _Float<N> type.

But in changing the mangling, we have the potential to create compatibility
issues, of code compiled with previous GCC's that use explicit __ibm128 and
__float128 keywords.  I don't how the users of these keywords (i.e. typically
libstdc++ and glibc developers, but potentially others as well).

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

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