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. 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
