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? Jason
