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

[Hubert Tong via cfe-commits]

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