rjmccall added a comment. In http://reviews.llvm.org/D15120#336855, @hubert.reinterpretcast wrote:
> 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". Perhaps; I don't know those rules at all. > > 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. That's only when the operand value is actually outside of the range of the type, which for implementations claiming IEEE 754 compatibility means "never" because of the infinities. Even if it weren't specified, every implementation I know of in practice does give this defined behavior using the active FP rounding rules. Anyway, I think we're agreed that we should just give make float128_t higher rank on all platforms. 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
