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