__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