[PATCH] D15120: Add support for __float128 type to be used by targets that support it
Hubert Tong via cfe-commits
cfe-commits at lists.llvm.org
Tue Jan 26 17:42:20 PST 2016
hubert.reinterpretcast added a comment.
In http://reviews.llvm.org/D15120#336827, @rjmccall wrote:
> Here's the thing, though: I don't think there's a reasonable language solution here besides saying that float128_t has higher rank. You can't make the types incompatible, because it's clearly reasonable to simply convert one to the other. What you're trying to say is that they don't have a common type, but it's a novel concept in C/C++ to have two arithmetic types that don't have a common type and therefore cannot be added / compared / ternary'd together. In contrast, it is not a novel concept to have a type that implicitly promotes to another type but potentially loses precision, because all the integer types will happily convert to float/double.
I believe that decimal floating point types introduced the situation of having two arithmetic types that don't have a common type into "C".
> This patch will be much simpler, and you will get a better language design, if you simply make float128_t a new FP type with a higher rank than long double.
The C committee decided that "undefined behavior" was what they could agree on for this sort of case. I suppose that on most platforms float128_t logically has the higher rank and it would be a shame to have source portability issues because the expression would need more casts on PPC. Even the narrowing conversion semantics in C++ is fine with losing precision.
More information about the cfe-commits