https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 53559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53559&action=edit gcc13-pr106652-lib.patch Some unfinished library changes. Unfortunately, we seem to have a major problem with glibc. <bits/floatn.h> included from <math.h> etc. on some arches does: # if __HAVE_FLOAT128 /* The type _Float128 exists only since GCC 7.0. */ # if !__GNUC_PREREQ (7, 0) || defined __cplusplus typedef __float128 _Float128; # endif ... #endif or typedef long double _Float128; etc. I'm afraid we'll need to fixincludes that and change in glibc. The question is to what exactly. I think with the compiler patch _Float<N> are in C++ generally available as keyword but __STDCPP_FLOAT<N>_T__ that the libstdc++ patch is using is only defined for C++23. The F<N> or f<N> literal suffixes pedwarn before C++23 but bet not in system headers, so glibc then could use those for C++ always for __GNUC_PREREQ (13, 0)?
