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