rjmccall added a comment. In http://reviews.llvm.org/D15120#337975, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#337654, @rjmccall wrote: > > > In http://reviews.llvm.org/D15120#337552, @hubert.reinterpretcast wrote: > > > > > 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 can reach out to someone who is involved. Thank you. If they have a strong motivation here, that's fine, but this feels like it would block and complicate future standardization efforts, as well as impair portability. > > > 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? > > > It appears that Clang does not currently support that option Ok. It would be better if we can avoid that, I think. > ; however, there are platforms where `long double` is already IEEE quad, > e.g., s390x-ibm-linux-gnu (where I have not found a GCC providing > `__float128`). Sure, that's a legitimate platform ABI choice. > It appears that we can defer the issue as long as we do not provide > `__float128` when `long double` is already IEEE quad. Sounds good. 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
