__float128 typeinfo

Joseph S. Myers joseph@codesourcery.com
Fri Jun 6 16:55:00 GMT 2014


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
joseph@codesourcery.com



More information about the Gcc-patches mailing list