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
