hubert.reinterpretcast added a comment. 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). > 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. 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. Repository: rL LLVM http://reviews.llvm.org/D15120 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
