[PATCH] D15120: Add support for __float128 type to be used by targets that support it

John McCall via cfe-commits cfe-commits at lists.llvm.org
Wed Jan 27 13:31:04 PST 2016

rjmccall added a comment.

In http://reviews.llvm.org/D15120#337552, @hubert.reinterpretcast wrote:

> In http://reviews.llvm.org/D15120#337384, @rjmccall wrote:
> > I think it's not unlikely that float128_t will see future standardization (as an optional extension, of course), and it would be strange for an operation between two types to not consistently yield the type of higher rank.
> It remains that the present standardization effort (as `_Float128`) does not imbue the "interchange" type with inherently higher rank than `long double`. In a parallel to the treatment of extended integer types, the "standard" type has higher rank when the set of values are equivalent between the two. This is consistent with the GCC implementation (online compiler: http://melpon.org/wandbox/permlink/tM3PyGWC5WTWIdKP).

Do we have anyone involved in this standardization effort?  It seems like a really poor idea to having type ranking be target-dependent.

> > I could see an argument that we should not treat float128_t as a distinct type from long double on targets where they have the same implementation.  That might avoid the need for special-case manglings.



> I would prefer this as well (insofar as it saves us from the common type issue). As I have mentioned before, for `__float128` and `-mlong-double-128` on x86-64, GCC ends up with an undesirable situation of treating the types as distinct, but mangling them the same.

Does Clang currently support that option?

> In the TS, `_Float128` is always distinct from `long double`, which is helpful for portability of `_Generic` expressions with both types. In the end, it seems to come down to what sort of code people will write. If overloads for both `__float128` and `long double` are the norm, then we will need to consider the types distinct.

Makes sense.



More information about the cfe-commits mailing list