This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: __float128 typeinfo
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: Jason Merrill <jason at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, <libstdc++ at gcc dot gnu dot org>, <meissner at linux dot vnet dot ibm dot com>, <ramana dot gcc at googlemail dot com>
- Date: Fri, 6 Jun 2014 18:08:59 +0000
- Subject: Re: __float128 typeinfo
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1406061049520 dot 8194 at stedding dot saclay dot inria dot fr> <5391E09A dot 7010607 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1406061740590 dot 22367 at stedding dot saclay dot inria dot fr> <5391EE69 dot 4080908 at redhat dot com> <alpine dot DEB dot 2 dot 02 dot 1406061900440 dot 23287 at stedding dot saclay dot inria dot fr>
On Fri, 6 Jun 2014, Marc Glisse wrote:
> DJ Delorie's work on __intN may be a good direction for __floatN as well, IIUC
> we will have a global list of 4 __intN types, and the target decides the value
> of N for each of them, so we can refer to those type nodes in common code but
> they are still target-specific. Or maybe there isn't enough variety in float
> types to deserve this.
The binary types in TS 18661-3 are:
- _FloatN, where N is 16, 32, 64, or >= 128 and a multiple of 32
- _Float32x
- _Float64x
- _Float128x
(_Float32, _Float64, _Float32x required; the first two same representation
and alignment as float and double; other types optional. _Float32x likely
to be same representation and alignment as double. _Float64x likely to be
same representation and alignment as __float80 where that's supported, or
__float128 where that's supported but __float80 isn't. All of these types
have IEEE semantics for their operations, so IBM long double would not be
used for any of them. All these types are distinct from each other and
from float / double / long double. All these types have corresponding
_Complex types. Obviously there are ABI issues with compatibility with
other implementations when supporting these types, although I doubt there
will be much difficulty with those in practice. To support these in C++
you'd need mangling defined.)
I don't really expect anything other than _Float16, _Float32, _Float64,
_Float128, _Float32x (= binary64), _Float64x (= __float80 or binary128) to
be widely used in the near future, though you might still want generic
_FloatN support (and would need it to a certain extent, to process
unsupported types meeting the given pattern as keywords rather than
identifiers then give an error that the type isn't supported).
--
Joseph S. Myers
joseph@codesourcery.com