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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
