https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #1) > (In reply to Rainer Orth from comment #0) > > * I initially tried aliasing __float128 to _Float128, but that broke the > > libstdc++ build: > > Libstdc++ could be changed to handle it, but I don't think we want that. > > In C++ the _FloatN types have special rules that prevent some implicit > conversions, which would break existing code that uses __float128 and > expects it to have the usual implicit conversions e.g. to double. Aliasing __float128 to _Float128 is wrong for C++. The latter has the standard required behavior for std::float128_t, while the former doesn't and shouldn't. I think best just leave __float128 not implemented. E.g. loongarch enabled it recently and ran into issues with e.g. libquadmath all of sudden being built when it shouldn't etc. If you really want to implement it, then it should be a distinct REAL_TYPE from both long_double_type and float128_type_node and you need to also enable the q/Q suffixes on floating point literals.
