Sorry for the slow reply to this.
On Fri, 7 Aug 2020 at 22:14, Michael Meissner <[email protected]> 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.
