__float128 typeinfo
Joseph S. Myers
joseph@codesourcery.com
Fri Jun 6 18:09:00 GMT 2014
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
More information about the Gcc-patches
mailing list