PowerPC long double Mangling

[Jonathan Wakely]

Sorry for the slow reply to this.

On Fri, 7 Aug 2020 at 22:14, Michael Meissner <meissner@linux.ibm.com> wrote:
>
> One issue with doing the transition is what mangling should be used with the
> new long double.
>
> At the moment, the current mangling is:
>         long double     "g"
>         __float128      "u9__ieee128"
>         __ibm128        "g"
>
> Obviously this will have to change in the future.  It is unfortunate that we
> choose "g" to mean IBM extended double many many years ago, when it should have
> been used for IEEE 128-bit floating point.  But that is long ago, so I think we
> need to keep it.
>
> But assuming we want compatibility with libraries like glibc and libstdc++, I
> think we will have to continue to use "g" for __ibm128.
>
> With the long double change, I tend to view this as an ABI change.  But if the
> user doesn't use long double, they should be able to link without changes.
>
> I would propose using a new mangling for IEEE 128-bit long double.  I would
> prefer to get agreement on what the new mangling should be so we don't have an
> issue like we had in GCC 8.1 going to GCC 8.2, where we changed the mangling,
> and had to provide aliases for the old name.
>
> At the moment I think the mangling should be:
>         long double     "g"                     if long double is IBM
>         long double     "u12_ieee128_ld"        if long double is IEEE
>         __float128      "u9__ieee128"
>         __ibm128        "g"

What's the benefit of having __float128 and IEEE long double be
distinct types? That complicates things for libraries like libstdc++.
If we want to support using "__float128" with C++ iostreams then we
need yet another set of I/O routines, even though it's identical to
one of the types we already handle. Why not just keep __float128 and
__ieee128 and "long double when long double is IEEE" as three
different aliases for the same type, so that C++ code like
_Z4funcu9__ieee128 works for all of them, instead of needing to also
define _Z4funcu12__ieee128_ld?

What about the "__ieee128" type, would that be mangled as
"u12_ieee128_ld" or "u9__ieee128"?

Currently it's the latter, i.e. __ieee128 is the same type as
__float128, which is the same type as "long double when
-mabi=ieeelongdouble". That seems useful to me, because it means that
I can always use either __ibm128 or __ieee128 to refer to "the type
that is sometimes known as 'long double'" irrespective of which -mabi
is actually used.

Today's mangling means I can declare a function in a header file as:

void func(long double);

and then in a library provide two definitions of that function, with
the right one being chosen by the linker depending what mangled name
it uses for "func(long double)" e.g. the definitions would be:

void func(__ibm128) { }
void func(__ieee128) { }

If __ieee128 is mangled to u9__ieee128, then if you compile the header
with -mabi=ieeelongdouble you can't link to the definition. To make it
work with the proposed mangling, the definitions would have to be:

void func(__ibm128) { }
void func(long double) { }

and then using -mabi=ieeelongdouble to compile the file would be
mandatory. That isn't terrible, but it seems inconsistent and
asymmetrical.

I'd also find it surprising if __ieee128 is not mangled to u9__ieee128
since that's its name :-) But that's far less important than the
practical matter of which types are mangled to the same and which
overloads are equivalent to each other.