rjmccall added a comment. In http://reviews.llvm.org/D15120#336996, @hubert.reinterpretcast wrote:
> In http://reviews.llvm.org/D15120#336891, @rjmccall wrote: > > > > 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. > > > The applicable wording is quoted here: http://reviews.llvm.org/D15120#310972, > but I guess that's unimportant for the purposes this discussion now. Oh, I see, you were referring to an FP->FP conversion rule, whereas I was still talking about the int->FP conversion rule as an example where C accepts converting to a common FP type even when it loses precision. That TS rule is extremely strange; I wonder whether they really mean "undefined", or if they just mean "implementation-defined", or if they just meant to say that it's UB if the original value isn't a member of the result type. I really don't know why you would intentionally give an entire statically-determined operation dynamically undefined behavior instead of simply making it ill-formed. Sometimes TSes aren't drafted very carefully. Oh well, a question for another day. 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
