Re: [PATCH] rs6000: Fix mangling for 128-bit float

[Jason Merrill <jason at redhat dot com>]

On Wed, May 30, 2018 at 11:32 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Wed, May 30, 2018 at 11:03:39AM -0400, Jason Merrill wrote:
>> On Wed, May 30, 2018 at 9:45 AM, Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>> > On Wed, May 30, 2018 at 03:15:21PM +0200, Jakub Jelinek wrote:
>> >> On Wed, May 30, 2018 at 12:58:49PM +0000, Segher Boessenkool wrote:
>> >> > This patch changes the (C++) mangling of the 128-bit float types:
>> >> >
>> >> >     __ieee128 becomes u9__ieee128
>> >> >     __ibm128 becomes u8__ieee128
>> >>
>> >> ^^^^^^ what is the advantage/reason for the above, rather than mangling it
>> >> as g?
>> >>
>> >> >     __float128 is not a type anymore
>> >> >     IEEE long double becomes u9__ieee128
>> >> >     IBM long double stays g
>> >>
>> >> I mean, the above change will mean a significant burden e.g. on libstdc++,
>> >> when we have to export all symbols that refer to the
>> >> long double/__ieee128/__ibm128 types 4 times, once as aliases to symbols
>> >> with double instead (with the exception when there is no such double
>> >> symbol) using mangling e, then make sure libstdc++ files are all compiled
>> >> with long double equal to IBM to get the g mangling, then add aliases to
>> >> those for u8__ieee128 and finally build with __ieee128 or long double equal
>> >> to IEEE754 quad to get the u9__ieee128 mangling.
>> >> And besides libstdc++ on everything else that wants to achieve ABI
>> >> compatibility with both formats.
>> >>
>> >> The above doesn't make long double distinct type from __ieee128 when it
>> >> is the same binary type anyway, so why should long double be distinct from
>> >> __ibm128 when long double is the same binary type as __ibm128?
>> >>
>> >> If you need to keep g for compatibility (you do), then why not just have
>> >> e (long double is double)
>> >> g (long double when matching __ibm128, or explicit __ibm128)
>> >> u9__ieee128 (long double when matching __ieee128, or explicit __ieee128)
>> >
>> > "g" means __float128.  Which is __ieee128.  And it has to be, because
>> > so much code expects that already, and it will only become more.  But
>> > "g" is demangled as __float128.  Confusion galore.
>> >
>> > We need to keep "g" mangling for compatibility, but over time everything
>> > will default to quad precision long double so people will only see the
>> > explicit __ibm128 anymore (if they use __ibm128 at all).
>> >
>> > The plan is to have the compiler generate the aliases (g vs. u8__ibm128)
>> > by itself, btw.
>>
>> Then how about
>>
>> e (long double is double)
>> u8__ibm128 (long double when matching __ibm128, or explicit __ibm128)
>> u9__ieee128 (long double when matching __ieee128, or explicit __ieee128)
>>
>> and 'g' only in compatibility aliases?
>
> Yes, but we can't switch to that until we have the aliases :-)

> And we may not want to switch on (older) archs that cannot have ieee128
> at all.

Sure.  But they can continue to be the same type, and therefore use
the same mangling, whichever mangling that is.  :)

Jason