[PATCH] D15120: Add support for __float128 type to be used by targets that support it

[John McCall via cfe-commits]

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