[PATCH] D109751: [Clang] Support conversion between PPC double-double and IEEE float128

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.


================
Comment at: clang/test/Sema/float128-ld-incompatibility.cpp:13
+long double ld{qf()}; // expected-error {{non-constant-expression cannot be narrowed from type '__float128' to 'long double' in initializer list}} expected-note {{insert an explicit cast to silence this issue}}
+__float128 q{ldf()}; // expected-no-error
 
----------------
hubert.reinterpretcast wrote:
> hubert.reinterpretcast wrote:
> > Should also test `__ibm128` cases.
> The C++ committee has advised that this implicit conversion should be considered ill-formed (see other comment).
> 
> Note that the //allowed// implicit conversion from `__ibm128` to `long double` (and vice versa) is still a conversion, which means that overload resolution is still a problem:
> ```
> void f(__ibm128);
> void f(int);
> void g(long double d) { return f(d); } // okay with GCC but not Clang; https://godbolt.org/z/fonsEbbY1
> ```
Even if the implicit conversion is to be allowed, there is not much reason why this is not considered narrowing (given the revised definition of narrowing conversions).

GCC's behaviour around the narrowing check has limited value as a reference point: Which of `__float128` or `__ibm128` is considered by GCC on Power to be the "wider type" depends on the `-mabi` option. That is, the behaviour is not consistent with there being a principled decision made by the GCC developers as to which representation format is "wider".


================
Comment at: clang/test/Sema/float128-ld-incompatibility.cpp:36-37
   q / ld; // expected-error {{invalid operands to binary expression ('__float128' and 'long double')}}
-  ld = q; // expected-error {{assigning to 'long double' from incompatible type '__float128'}}
-  q = ld; // expected-error {{assigning to '__float128' from incompatible type 'long double'}}
+  ld = q; // expected-no-error {{assigning to 'long double' from incompatible type '__float128'}}
+  q = ld; // expected-no-error {{assigning to '__float128' from incompatible type 'long double'}}
   q + b ? q : ld; // expected-error {{incompatible operand types ('__float128' and 'long double')}}
----------------
hubert.reinterpretcast wrote:
> The C++ committee has advised that these are not okay as implicit conversions:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1467r7.html#implicit
> 
> Additional lines testing `static_cast` would be appropriate.
> 
I guess this could be controversial since converting from `__float128` to `float` (for example) would also be prohibited (if `__float128` were to be considered to be an extended floating-point type).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109751/new/

https://reviews.llvm.org/D109751