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

[Segher Boessenkool <segher at kernel dot crashing dot org>]

On Wed, May 30, 2018 at 06:43:23PM +0200, Jakub Jelinek wrote:
> On Wed, May 30, 2018 at 08:45:22AM -0500, Segher Boessenkool wrote:
> > > 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.
> 
> Is that such a big deal?  It hasn't been a problem in the past decade when
> it was similarly wrong too.  And, with the intent to phase out long double
> as __ibm128 (at least on powerpc64le) shortly only libstdc++ and perhaps a
> couple of other libraries will have this demangling glitch (and those will
> have it in any case, because there will be the compatibility aliases that
> will demangle as __float128).  So I really don't see any advantages of
> changing the __ibm128 and/or long double that is __ibm128 mangling from
> g to something else.  But I see severe disadvantages.
> 
> The libstdc++ changes to support both __ibm128 and __ieee128 will be very
> hard themselves, there is no need to complicate it further.

We're running some tests now with "g" mangling for everything double-double
(and u9__ieee128 for everything IEEE quad-precision float).

We think it will all work out, certainly for systems where double-double
in the future is just a bad memory (and for other systems the problems
are nothing new).

Thanks to you all for all the input,


Segher