On Wed, May 30, 2018 at 11:32 AM, Segher Boessenkool <seg...@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 >> <seg...@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
