On Fri, 6 Jun 2014, Jason Merrill wrote: > On 06/06/2014 11:58 AM, Marc Glisse wrote: > > On Fri, 6 Jun 2014, Jason Merrill wrote: > > > > > What's your rationale for keeping this in a separate version block > > > rather than in 1.3.9 (like __int128)? > > > > Powerpc already has those symbols in CXXABI_LDBL_1.3 (for a type that > > isn't __float128 but (de)mangles that way). That doesn't prevent from > > using CXXABI_1.3.9 in the x86/ia64-specific file though, so I can do > > that if you prefer. If a new target implements __float128 in 4.11 or > > 4.12, they will have to refine the configure test and provide a > > different .ver file to avoid adding symbols to an old version. > > Fair enough. Let's stick with your approach then, but drop the 1.3.9 from the > name. > > Why is __float128 handled as a target type, anyway? I'd think it ought to be > a standard type that just isn't supported on all targets, like __int128.
If we want something like that as a standard type not supported on all targets I'd think we should use the DTS 18661-3 naming (_Float128) and then make __float128 a typedef for that, at least for C. (I don't know if C++ would want peculiarities such as _Float128 being a distinct type from long double even if they have the same representation and alignment, so a conservative approach would be for _Float128 not to exist for C++ unless it's distinct. There are various other details in which _Float128 differs from __float128, e.g. it's a keyword and all _FloatN for N >= 128 and a multiple of 32 are keywords whether or not the type is supported. I imagine any C++ bindings would look somewhat different, like the C++ bindings to decimal floating point.) Both __float128 and __int128 names came from the x86_64 ABI. -- Joseph S. Myers jos...@codesourcery.com
