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

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added a comment.

In D109751#3178494 <https://reviews.llvm.org/D109751#3178494>, @qiucf wrote:

> Thanks for the reminder. Here GCC and Clang diverges in the handling of `__ibm128`/`__float128` and `long double`. Not sure whether GCC will 'fix' the behavior, but here (and in most of the use case in glibc headers) it's `__builtin_types_compatible_p(..., _Float128)` where GCC/Clang behaves the same.

I thought Clang doesn't have `_Float128` yet; that's D111382 <https://reviews.llvm.org/D111382>, which makes `_Float128` act like `__float128` (and, in turn, like `__ieee128`).

With `-mabi=ieeelongdouble`:

  extern char x[__builtin_types_compatible_p(long double, __float128) ? 1 : -1]; // GCC accepts; Clang rejects

https://godbolt.org/z/fGbY1Y1PT



================
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
 
----------------
qiucf wrote:
> hubert.reinterpretcast wrote:
> > 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".
> Thanks for the information. The behavior of GCC looks somewhat reasonable but I notice the naming convention of support functions is interesting: `__ibm128` to `__float128` is 'extend', `__float128` to `__ibm128` 'truncate'.
Did you try GCC with `-mabi=ieeelongdouble` and `-pedantic-errors`?

```
extern __ibm128 x;
long double q{ x }; // narrowing error
```
https://godbolt.org/z/3YazKv9f7



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109751