hubert.reinterpretcast added inline comments.
================ Comment at: clang/lib/Parse/ParseExprCXX.cpp:2245 + case tok::kw___ibm128: + DS.SetTypeSpecType(DeclSpec::TST_ibm128, Loc, PrevSpec, DiagID, Policy); + break; ---------------- jwakely wrote: > hubert.reinterpretcast wrote: > > jwakely wrote: > > > hubert.reinterpretcast wrote: > > > > qiucf wrote: > > > > > hubert.reinterpretcast wrote: > > > > > > qiucf wrote: > > > > > > > hubert.reinterpretcast wrote: > > > > > > > > Not sure what the best method is to implement this, but `long > > > > > > > > double` and `__ibm128` are the same type for GCC when > > > > > > > > `-mabi=ibmlongdouble` is in effect. > > > > > > > Seems clang is also different from GCC under > > > > > > > `-mabi=ieeelongdouble`? I saw `__float128` and `long double` are > > > > > > > the same for GCC but not for clang. > > > > > > Have you checked whether the new libstdc++ for which this support > > > > > > is being added needs the GCC behaviour to work properly? > > > > > > > > > > > > The GCC behaviour allows the following to be compiled without > > > > > > introducing novel overload resolution tiebreakers: > > > > > > ``` > > > > > > void f(__float128); > > > > > > void f(__ibm128); > > > > > > void f(int); > > > > > > > > > > > > long double ld; > > > > > > > > > > > > int main() { f(ld); } > > > > > > ``` > > > > > As I saw both GCC and clang have error for ambiguous `operator<<` for: > > > > > > > > > > ``` > > > > > std::cout << "long double:\n"; > > > > > std::cout << std::numeric_limits<long double>::max() << std::endl; > > > > > std::cout << std::numeric_limits<long double>::min() << std::endl; > > > > > > > > > > std::cout << "__float128:\n"; > > > > > std::cout << std::numeric_limits<__float128>::max() << std::endl; > > > > > std::cout << std::numeric_limits<__float128>::min() << std::endl; > > > > > > > > > > std::cout << "__ibm128:\n"; > > > > > std::cout << std::numeric_limits<__ibm128>::max() << std::endl; > > > > > std::cout << std::numeric_limits<__ibm128>::min() << std::endl; > > > > > ``` > > > > @jwakely, are the overload resolution errors expected? @qiucf, are you > > > > sure you have a sufficiently new libstdc++? > > > > @jwakely, are the overload resolution errors expected? > > > > > > Yes. Iostreams support `long double` but not `__float128`, unless that > > > happens to be the same type as `long double` (due to a > > > `-mabi=ieeelongdouble` option). > > Meaning that Clang's `__float128` iosteams support (with libstdc++) would > > diverge from GCC. > > > > For example, Clang reports the call below as ambiguous even with > > `-mabi=ieeelongdouble`: > > ``` > > void f(double); > > void f(long double); > > > > void g(__float128 f128) { f(f128); } > > ``` > > > > https://godbolt.org/z/dhYEKa > > > > Insofar as the user experience goes, is this lack of iostreams support for > > `__float128` (even with `-mabi=ieeelongdouble`) within the realm of the > > intended design of libstdc++? > The lack of iostreams support for `__float128` is the intended design. > > On power we support `float`, `double` and three types of `long double`. If > `__float128` is a distinct type from all those `long double` types it won't > work. > > GCC on power defines `__float128` as a macro expanding to `__ieee128`, so it > is the same as one of the `long double` types. Okay, it sounds like the different treatment Clang has does not really interfere with recommended usage insofar as libstdc++ iostreams (and hopefully this extends to the rest of the library). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93377/new/ https://reviews.llvm.org/D93377 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits