[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sat Sep 10 17:28:44 GMT 2022


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)?


More information about the Gcc-bugs mailing list