hubert.reinterpretcast added a comment.
In http://reviews.llvm.org/D15120#310992, @nemanjai wrote:
> I think the correct course of action would be to allow/disallow promotion
> based on a condition that the two types are the same/different
> (respectively). I think a comparison of the float semantics is a valid way to
> check this. Also, should operations between long double and __float128 be
> diagnosed as warnings or errors if the two types are distinct?
When the "two" types have the same float semantics, an additional consideration
is whether there are indeed two types, or if there is just one (with different
ways to name it). On x86_64 Linux systems, I believe that the latter case is
true for `__float80` and `long double` with GCC; however, with
`-mlong-double-128`, GCC treats `__float128` and `long double` as distinct (but
uses the same mangling for both). That is to say, GCC is inconsistent.
With regards to the usual arithmetic conversions, I believe that an error is
the safest course of action when the two types are distinct (between
PPCDoubleDouble and IEEEquad). It appears that the use of
`IsFloatingPointPromotion` for C is sketchy (see inline comments).
================
Comment at: lib/Sema/SemaOverload.cpp:1921-1922
@@ -1920,4 +1920,4 @@
// C99 6.3.1.5p1:
// When a float is promoted to double or long double, or a
// double is promoted to long double [...].
if (!getLangOpts().CPlusPlus &&
----------------
hubert.reinterpretcast wrote:
> In C99 6.3.1.5p1:
> > [...] its value is unchanged.
>
> Allowing `long double` to promote to `__float128` violates that on at least
> one target platform.
> For example, PPCDoubleDouble can represent (2^512) - 1 exactly.
>
The only "promotions" in C as of C11 are the integer promotions and the default
argument promotions. The (now removed) use of "promoted" to describe a
//conversion// between double to long double appears to have been an
unintentional overloading of the term. If the purpose of this function is as
described (to implement conv.fpprom), then the use of it for C appears to be
erroneous. At the very least, the comments are not sufficient and the naming of
the function (given its current implementation) no longer has a basis in the C
Standard.
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
