https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85518
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b04208895fed34171eac6bafb60c90048eb1cb0c
commit r13-2887-gb04208895fed34171eac6bafb60c90048eb1cb0c
Author: Jakub Jelinek
Date: Tue Sep 27 08:04:06 2022 +0200
c++: Implement P1467R9 - Extended floating-point types and standard names
compiler part except for bfloat16 [PR106652]
The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
mangling.
It also introduces _Float{32,64,128}x for C++ with the
https://github.com/itanium-cxx-abi/cxx-abi/pull/147
proposed mangling of DF{32,64,128}x.
The patch doesn't add anything for bfloat16_t support, as right now
__bf16 type refuses all conversions and arithmetic operations.
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc. So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are
distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type. The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at
least
one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx
are
also treated as extended floating-point types) and kept previous behavior
otherwise. For float/double/long double the rules are actually written
that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet). E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes. One gets
errors like:
In file included from /usr/include/math.h:43,
from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
86 | typedef __float128 _Float128;
| ^~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare
anything [-fpermissive]
86 | typedef __float128 _Float128;
|^
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one
declaration
214 | typedef float _Float32;
| ^
/usr/include/bits/floatn-common.h:214:15: error: declaration does not
declare anything [-fpermissive]
214 | typedef float _Float32;
| ^~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one
declaration
251 | typedef double _Float64;
| ^~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not
declare anything [-fpermissive]
251 | typedef double _Float64;
|^~~~
This is from snippets like:
/* The remaining of this file provides support for older compilers. */
# if __HAVE_FLOAT128
/* The type _Float128 exists only since GCC 7.0. */
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
typedef __float128 _Float128;
# endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x}
support nor
{f,F}{16,32,64,128}{,x} literal suffixes nor _Complex
_Float{16,32,64,128,32x,64x,128x}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those. The patch changes those
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13,
0))
Another thing is mangling, as said above, Itanium C++ ABI specifies
DF _ as _Float{16,32,64,128} mangling, but GCC was implementing
a mangling incompatible with that starting with DF for fixed point types.
Fixed point was never supported in C++ though, I believe the reason why
the mangling has been added was that due to a bug it would leak into the
C++ FE through decltype (0.0r) etc.
