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. Segher
