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

Hubert Tong via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Dec 4 08:47:26 PST 2021

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).

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list