This reverts commit 7d454cae.

The change breaks bootstrap on some x86_64 OS versions.

The fix is unnecessary on macOS.

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def (stdio_stdarg_h): Skip on darwin.

Headers are now fixed in the macOS 15 SDK, and the fix should be
bypassed there.

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def (darwin_objc_runtime_1): Add bypass.

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def (apple_local_stdio_fn_deprecation): Also apply to
	_stdio.h.

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def (math_exception): Bypass on __cplusplus.
	* tests/base/math.h: Regenerate.

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def (darwin_stdint_7, darwin_dispatch_object_1,
	darwin_os_trace_2, darwin_os_base_1): Include bypasses
	for recent headers, fixed by Apple.

Add the initial aarch64-w64-mingw32 target for gcc.

This is the first commit in a sequence of patch series to add
new aarch64-w64-mingw32 target.

Coauthors: Zac Walker <zacwalker@microsoft.com>,
Mark Harmstone <mark@harmstone.com>  and
Ron Riddle <ron.riddle@microsoft.com>

Refactored, prepared, and validated by
Radek Barton <radek.barton@microsoft.com> and
Evgeny Karpov <evgeny.karpov@microsoft.com>

fixincludes/ChangeLog:

	* mkfixinc.sh: Extend for *-mingw32* targets.

gcc/ChangeLog:

	* config.gcc: Add aarch64-w64-mingw32 target.

The stray line defining enable_darwin_at_rpath outside of the scope of
_LT_DARWIN_LINKER_FEATURES is a mistake and should be removed. It leads
to a wrong line in fixincludes/ChangeLog because there is no $1 argument
at that point.

ChangeLog:

	* libtool.m4: Fix stray call

fixincludes/ChangeLog:

	* configure: Regenerated.

This corrects an oversight in the r14-4825 commit.

fixincludes/ChangeLog:

	* configure: Regenerate.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

On macOS 14, a guard in <math.h> changed:

-- MacOSX13.3.sdk/usr/include/math.h	2023-04-19 01:54:44
+++ MacOSX14.0.sdk/usr/include/math.h	2023-08-01 08:42:43
@@ -22,0 +23 @@
+
@@ -43 +44 @@
-#if __FLT_EVAL_METHOD__ == 0
+#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == -1
@@ -49 +50 @@
-#elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1
+#elif __FLT_EVAL_METHOD__ == 2

Therefore the darwin_flt_eval_method fixincludes fix doesn't match any
longer, leading to a large number of testsuite failures like

/private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed/math.h:69:5:
error: #error "Unsupported value of __FLT_EVAL_METHOD__."

where __FLT_EVAL_METHOD__ = 16.

This patch adjusts the fix to allow for both forms.

Tested with make check in fixincludes on x86_64-apple-darwin23.0.0 and
verifying that <math.h> has indeed been fixed as expected.

2023-08-16  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	fixincludes:
	* inclhack.def (darwin_flt_eval_method): Handle macOS 14 guard
	variant.
	* fixincl.x: Regenerate.
	* tests/base/math.h [DARWIN_FLT_EVAL_METHOD_CHECK]: Update test.

Libtool needs to get BSD-format (or MS-format) output out of the system
nm, so that it can scan generated object files for symbol names for
-export-symbols-regex support.  Some nms need specific flags to turn on
BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
Unfortunately the code to do this has a pair of interlocking flaws:

 - it runs the test by doing an nm of /dev/null.  Some platforms
   reasonably refuse to do an nm on a device file, but before now this
   has only been worked around by assuming that the error message has a
   specific textual form emitted by Tru64 nm, and that getting this
   error means this is Tru64 nm and that nm -B would work to produce
   BSD-format output, even though the test never actually got anything
   but an error message out of nm -B.  This is fixable by nm'ing *nm
   itself* (since we necessarily have a path to it).

 - the test is entirely skipped if NM is set in the environment, on the
   grounds that the user has overridden the test: but the user cannot
   reasonably be expected to know that libtool wants not only nm but
   also flags forcing BSD-format output.  Worse yet, one such "user" is
   the top-level Cygnus configure script, which neither tests for
   nor specifies any BSD-format flags.  So platforms needing BSD-format
   flags always fail to set them when run in a Cygnus tree, breaking
   -export-symbols-regex on such platforms.  Libtool also needs to
   augment $LD on some platforms, but this is done unconditionally,
   augmenting whatever the user specified: the nm check should do the
   same.

   One wrinkle: if the user has overridden $NM, a path might have been
   provided: so we use the user-specified path if there was one, and
   otherwise do the path search as usual.  (If the nm specified doesn't
   work, this might lead to a few extra pointless path searches -- but
   the test is going to fail anyway, so that's not a problem.)

(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
*that* is a symlink to /usr/bin/nm.)

ChangeLog:

	* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
	NM, if there is one.  Run nm on itself, not on /dev/null, to avoid
	errors from nms that refuse to work on non-regular files.  Remove
	other workarounds for this problem.  Strip out blank lines from the
	nm output.

fixincludes/ChangeLog:

	* configure: Regenerate.

gcc/ChangeLog:

	* configure: Regenerate.

libatomic/ChangeLog:

	* configure: Regenerate.

libbacktrace/ChangeLog:

	* configure: Regenerate.

libcc1/ChangeLog:

	* configure: Regenerate.

libffi/ChangeLog:

	* configure: Regenerate.

libgfortran/ChangeLog:

	* configure: Regenerate.

libgm2/ChangeLog:

	* configure: Regenerate.

libgomp/ChangeLog:

	* configure: Regenerate.

libitm/ChangeLog:

	* configure: Regenerate.

libobjc/ChangeLog:

	* configure: Regenerate.

libphobos/ChangeLog:

	* configure: Regenerate.

libquadmath/ChangeLog:

	* configure: Regenerate.

libsanitizer/ChangeLog:

	* configure: Regenerate.

libssp/ChangeLog:

	* configure: Regenerate.

libstdc++-v3/ChangeLog:

	* configure: Regenerate.

libvtv/ChangeLog:

	* configure: Regenerate.

lto-plugin/ChangeLog:

	* configure: Regenerate.

zlib/ChangeLog:

	* configure: Regenerate.

[ This is my third attempt to add this configure option.  The first
version was approved but it came too late in the development cycle.
The second version was also approved, but I had to revert it:
<https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607082.html>.
I've fixed the problem (by moving $(PICFLAG) from INTERNAL_CFLAGS to
ALL_COMPILERFLAGS).  Another change is that since r13-4536 I no longer
need to touch Makefile.def, so this patch is simplified. ]

This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE.  This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.

It is similar to the option --enable-host-shared, except that --e-h-s
won't add -shared to the linker flags whereas --e-h-p will add -pie.
It is different from --enable-default-pie because that option just
adds an implicit -fPIE/-pie when the compiler is invoked, but the
compiler itself isn't PIE.

Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH
regressions.

When building the compiler, the build process may use various in-tree
libraries; these need to be built with -fPIE so that it's possible to
use them when building a PIE.  For instance, when --with-included-gettext
is in effect, intl object files must be compiled with -fPIE.  Similarly,
when building in-tree gmp, isl, mpfr and mpc, they must be compiled with
-fPIE.

With this patch and --enable-host-pie used to configure gcc:

$ file gcc/cc1{,plus,obj,gm2} gcc/f951 gcc/lto1 gcc/cpp gcc/go1 gcc/rust1 gcc/gnat1
gcc/cc1:     ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=98e22cde129d304aa6f33e61b1c39e144aeb135e, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cc1plus: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=859d1ea37e43dfe50c18fd4e3dd9a34bb1db8f77, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cc1obj:  ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1964f8ecee6163182bc26134e2ac1f324816e434, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cc1gm2:  ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a396672c7ff913d21855829202e7b02ecf42ff4c, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/f951:    ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=59c523db893186547ac75c7a71f48be0a461c06b, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/lto1:    ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=084a7b77df7be2d63c2d4c655b5bbc3fcdb6038d, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/cpp:     ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3503bf8390d219a10d6653b8560aa21158132168, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/go1:     ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=988cc673af4fba5dcb482f4b34957b99050a68c5, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/rust1:   ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b6a5d3d514446c4dcdee0707f086ab9b274a8a3c, for GNU/Linux 3.2.0, with debug_info, not stripped
gcc/gnat1:   ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb11ccdc2c366fe3fe0980476bcd8ca19b67f9dc, for GNU/Linux 3.2.0, with debug_info, not stripped

I plan to add an option to link with -Wl,-z,now.

Bootstrapped on x86_64-pc-linux-gnu with --with-included-gettext
--enable-host-pie as well as without --enable-host-pie.  Also tested
on a Debian system where the system gcc was configured with
--enable-default-pie.

Co-Authored by: Iain Sandoe  <iain@sandoe.co.uk>

ChangeLog:

	* configure.ac (--enable-host-pie): New check.  Set PICFLAG after this
	check.
	* configure: Regenerate.

c++tools/ChangeLog:

	* Makefile.in: Rename PIEFLAG to PICFLAG.  Set LD_PICFLAG.  Use it.
	Use pic/libiberty.a if PICFLAG is set.
	* configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG.
	(--enable-host-pie): New check.
	* configure: Regenerate.

fixincludes/ChangeLog:

	* Makefile.in: Set and use PICFLAG and LD_PICFLAG.  Use the "pic"
	build of libiberty if PICFLAG is set.
	* configure.ac:
	* configure: Regenerate.

gcc/ChangeLog:

	* Makefile.in: Set LD_PICFLAG.  Use it.  Set enable_host_pie.
	Remove NO_PIE_CFLAGS and NO_PIE_FLAG.  Pass LD_PICFLAG to
	ALL_LINKERFLAGS.  Use the "pic" build of libiberty if --enable-host-pie.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
	check.
	* configure: Regenerate.
	* doc/install.texi: Document --enable-host-pie.

gcc/ada/ChangeLog:

	* gcc-interface/Make-lang.in (ALL_ADAFLAGS): Remove NO_PIE_CFLAGS.  Add
	PICFLAG.  Use PICFLAG when building ada/b_gnat1.o and ada/b_gnatb.o.
	* gcc-interface/Makefile.in: Use pic/libiberty.a if PICFLAG is set.
	Remove NO_PIE_FLAG.

gcc/m2/ChangeLog:

	* Make-lang.in: New var, GM2_PICFLAGS.  Use it.

gcc/d/ChangeLog:

	* Make-lang.in: Remove NO_PIE_CFLAGS.

intl/ChangeLog:

	* Makefile.in: Use @PICFLAG@ in COMPILE as well.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libcody/ChangeLog:

	* Makefile.in: Pass LD_PICFLAG to LDFLAGS.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
	check.
	* configure: Regenerate.

libcpp/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libdecnumber/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libiberty/ChangeLog:

	* configure.ac: Also set shared when enable_host_pie.
	* configure: Regenerate.

zlib/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

memmem is not POSIX so the system may lack it.  Then libiberty will
provide an implementation, but it's a "supplemental function" and not
declared in libiberty.h.  We need to declare the prototype to use it
then.

See libiberty doc at
https://gcc.gnu.org/onlinedocs/libiberty/Supplemental-Functions.html.

Tested by bootstrapping GCC in the following container environments on
x86_64-linux-gnu:

1. "Vanilla" system with memmem in Glibc.
2. memmem removed from string.h.
3. memmem removed from both string.h and libc.so.

For 3, also verified that memmem from libiberty is linked into fixincl
executable.

Ok for trunk?

fixincludes/ChangeLog:

	PR other/109293
	* configure.ac (AC_CHECK_DECLS): Add memmem.
	* configure: Regenerate.
	* config.h.in: Regenerate.
	* system.h (memmem): Declare if HAVE_DECL_MEMMEM is zero.

Solaris 11 <math.h> long had this snippet

which badly broke libstdc++.  This has long been undone using
fixincludes in

	[fixincludes, v3] Don't define libstdc++-internal macros in Solaris 10+ <math.h>
	https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html

However, the issue came up again recently when that code broke the LLVM
build, too, which unfortunately doesn't know about GCC's include-fixed
directory.  The issue was reinvestigated and it turned out that the
workaround/hack is only needed for specific old versions of the Sun/Oracle
Studio compilers.  So <math.h> now looks like

/* Accommodate historical C++11 -std=c++03 behavior of Studio 12.4 and 12.5 */
    ((__SUNPRO_CC == 0x5130) || (__SUNPRO_CC == 0x5140) ||  \
     defined(__MATH_PREEMPTS_GLIBCXX_C99_MATH))

If this change is in place, there's no longer a need for the fixincludes
fix, so this patch bypasses it as appropriate.

Tested on Solaris 11.3 (without the fixed header) and recent 11.4 (with
the fixed header).

2022-11-01  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	fixincludes:
	* inclhack.def (solaris_math_12): Add bypass.
	* fixincl.x: Regenerate.

The macOS 13 SDK has unguarded Apple Blocks use in objc/runtime.h which
causes most of the objective-c tests to fail.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def (darwin_objc_runtime_1): New hack.
	* tests/base/objc/runtime.h: New file.

The SDK for MacOS13 includes Apple-specific deprecations of some functions that
are not deprecated in Posix, C or C++ and widely used in GCC.

The fix makes the deprecation conditional on __APPLE_LOCAL_DEPRECATIONS so that
end users may still observe them but they are hidden from normal compilations.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

	PR target/107568

fixincludes/ChangeLog:

	* fixincl.x: Regenerate.
	* inclhack.def: Add a fix for MacOS13 SDK function deprecations
	in stdio.h.
	* tests/base/stdio.h (__deprecated_msg): New test.

This reverts commit 251c72a6.

This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE.  This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.

It is similar to the option --enable-host-shared, except that --e-h-s
won't add -shared to the linker flags whereas --e-h-p will add -pie.
It is different from --enable-default-pie because that option just
adds an implicit -fPIE/-pie when the compiler is invoked, but the
compiler itself isn't PIE.

Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH
regressions.

When building the compiler, the build process may use various in-tree
libraries; these need to be built with -fPIE so that it's possible to
use them when building a PIE.  For instance, when --with-included-gettext
is in effect, intl object files must be compiled with -fPIE.  Similarly,
when building in-tree gmp, isl, mpfr and mpc, they must be compiled with
-fPIE.

I plan to add an option to link with -Wl,-z,now.

ChangeLog:

	* Makefile.def: Pass $(PICFLAG) to AM_CFLAGS for gmp, mpfr, mpc, and
	isl.
	* Makefile.in: Regenerate.
	* Makefile.tpl: Set PICFLAG.
	* configure.ac (--enable-host-pie): New check.  Set PICFLAG after this
	check.
	* configure: Regenerate.

c++tools/ChangeLog:

	* Makefile.in: Rename PIEFLAG to PICFLAG.  Set LD_PICFLAG.  Use it.
	Use pic/libiberty.a if PICFLAG is set.
	* configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG.
	(--enable-host-pie): New check.
	* configure: Regenerate.

fixincludes/ChangeLog:

	* Makefile.in: Set and use PICFLAG and LD_PICFLAG.  Use the "pic"
	build of libiberty if PICFLAG is set.
	* configure.ac:
	* configure: Regenerate.

gcc/ChangeLog:

	* Makefile.in: Set LD_PICFLAG.  Use it.  Set enable_host_pie.
	Remove NO_PIE_CFLAGS and NO_PIE_FLAG.  Pass LD_PICFLAG to
	ALL_LINKERFLAGS.  Use the "pic" build of libiberty if --enable-host-pie.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
	check.
	* configure: Regenerate.
	* doc/install.texi: Document --enable-host-pie.

gcc/d/ChangeLog:

	* Make-lang.in: Remove NO_PIE_CFLAGS.

intl/ChangeLog:

	* Makefile.in: Use @PICFLAG@ in COMPILE as well.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libcody/ChangeLog:

	* Makefile.in: Pass LD_PICFLAG to LDFLAGS.
	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG and LD_PICFLAG after this
	check.
	* configure: Regenerate.

libcpp/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libdecnumber/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

libiberty/ChangeLog:

	* configure.ac: Also set shared when enable_host_pie.
	* configure: Regenerate.

zlib/ChangeLog:

	* configure.ac (--enable-host-shared): Don't set PICFLAG here.
	(--enable-host-pie): New check.  Set PICFLAG after this check.
	* configure: Regenerate.

On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Another case are the following 3 snippets:
> #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> #   error "_Float128X supported but no constant suffix"
> #  else
> #   define __f128x(x) x##f128x
> #  endif
> ...
> #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> #   error "_Float128X supported but no complex type"
> #  else
> #   define __CFLOAT128X _Complex _Float128x
> #  endif
> ...
> #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> #   error "_Float128x supported but no type"
> #  endif
> but as no target has _Float128x right now and don't see it
> coming soon, it isn't a big deal (on the glibc side it is of
> course ok to adjust those).

This incremental patch deals handles the above 3 cases, so we
fixinclude what glibc itself changed too.

2022-10-07  Jakub Jelinek  <jakub@redhat.com>

	PR bootstrap/107059
	* inclhack.def (glibc_cxx_floatn_5): New.
	* fixincl.x: Regenerated.
	* tests/base/bits/floatn.h: Regenerated.

On Wed, Sep 28, 2022 at 12:23:31AM +0000, Joseph Myers wrote:
> In general the changes match those made by fixincludes, though I think
> the ones in sysdeps/powerpc/bits/floatn.h, where the header tests
> __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing
> fixincludes patterns.

You're right, missed that.
The header has:
 /* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1.  */
 # if __HAVE_FLOAT128
 #  if __LDBL_MANT_DIG__ == 113 && defined __cplusplus
 typedef long double _Float128;
 #   define __CFLOAT128 _Complex long double
 #  elif !__GNUC_PREREQ (7, 0) || defined __cplusplus
 /* The type _Float128 exist for powerpc only since GCC 7.0.  */
 typedef __float128 _Float128;
 /* Add a typedef for older GCC and C++ compilers which don't natively support
    _Complex _Float128.  */
 typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
 #   define __CFLOAT128 __cfloat128
 #  else
 #   define __CFLOAT128 _Complex _Float128
 #  endif
 # endif
and my current rules don't do anything about that.

The following patch fixes that.
I've run additionally
MACRO_LIST=`pwd`/../gcc/macro_list TARGET_MACHINE=x86_64-pc-linux-gnu \
  ../fixincludes/fixinc.sh /tmp/include-fixed \
    `echo /usr/src/libc | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
in the builddir/fixincludes directory where /usr/src/libc is latest glibc
trunk checkout and seems the remaining defined __cplusplus cases in the floatn.h
and floatn-common.h headers are ok or acceptable.
The remaining cases are:
 #if __GNUC_PREREQ (7, 0) && !defined __cplusplus
 # define __HAVE_FLOATN_NOT_TYPEDEF 1
 #else
 # define __HAVE_FLOATN_NOT_TYPEDEF 0
 #endif
which is IMHO ok because this is only used in tgmath.h or tgmath-like math.h
stuff which is C only, as C++ doesn't have _Generic.
Another case are the following 3 snippets:
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 #   error "_Float128X supported but no constant suffix"
 #  else
 #   define __f128x(x) x##f128x
 #  endif
...
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 #   error "_Float128X supported but no complex type"
 #  else
 #   define __CFLOAT128X _Complex _Float128x
 #  endif
...
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 #   error "_Float128x supported but no type"
 #  endif
but as no target has _Float128x right now and don't see it
coming soon, it isn't a big deal (on the glibc side it is of
course ok to adjust those).
OT, besides floatn.h and floatn-common.h headers, the only
one remaining in /tmp/include-fixed is sysdeps/arm/unwind.h, perhaps
-#if defined(linux) || defined(__NetBSD__)
+#if defined(__linux__) || defined(__NetBSD__)
should be done in that header (and libgcc/config/arm/unwind-arm.h
too).

2022-10-07  Jakub Jelinek  <jakub@redhat.com>

	PR bootstrap/107059
	* inclhack.def (glibc_cxx_floatn_2): Handle #elif the same as #if.
	(glibc_cxx_floatn_4): New.
	* fixincl.x: Regenerated.
	* tests/base/bits/floatn.h: Regenerated.

As reported by Tobias, my C++ _Float{16,32,64,128,32x,64x,128x} support
patch broke Debian/Ubuntu bootstraps.  The problem is that there
glibc bits/floatn.h and bits/floatn-common.h isn't in /usr/include/
directly, but in a subdirectory like /usr/include/x86_64-linux-gnu/
Seems other fixinclude rules for bits/* headers use
files = bits/whatever.h, "*/bits/whatever.h";
so this patch just follows the suit.

2022-06-27  Jakub Jelinek  <jakub@redhat.com>

	* inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
	glibc_cxx_floatn_3): Add to files also "*/bits/floatn.h"
	and "*/bits/floatn-common.h".
	* fixincl.x: Regenerated.

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 <number> _ 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.  But that has been shortly after the
mangling was added fixed (I think in the same GCC release cycle), so we
now reject 0.0r etc. in C++.  If we ever need the fixed point mangling,
I think it can be readded but better with a different prefix so that it
doesn't conflict with the published standard manglings.  So, this patch
also kills the fixed point mangling and implements the DF <number> _
demangling.
The patch predefines __STDCPP_FLOAT{16,32,64,128}_T__ macros when
those types are available, but only for C++23, while the underlying types
are available in C++98 and later including the {f,F}{16,32,64,128} literal
suffixes (but those with a pedwarn for C++20 and earlier).  My understanding
is that it needs to be predefined by the compiler, on the other side
predefining even for older modes when <stdfloat> is a new C++23 header
would be weird.  One can find out if _Float{16,32,64,128,32x,64x,128x} is
supported in C++ by
__GNUC__ >= 13 && defined(__FLT{16,32,64,128,32X,64X,128X}_MANT_DIG__)
(but that doesn't work well with older G++ 13 snapshots).

As for std::bfloat16_t, three targets (aarch64, arm and x86) apparently
"support" __bf16 type which has the bfloat16 format, but isn't really
usable, e.g. {aarch64,arm,ix86}_invalid_conversion disallow any conversions
from or to type with BFmode, {aarch64,arm,ix86}_invalid_unary_op disallows
any unary operations on those except for ADDR_EXPR and
{aarch64,arm,ix86}_invalid_binary_op disallows any binary operation on
those.  So, I think we satisfy:
"If the implementation supports an extended floating-point type with the
properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2, storage
width in bits (k) of 16, precision in bits (p) of 8, maximum exponent (emax)
of 127, and exponent field width in bits (w) of 8, then the typedef-name
std::bfloat16_t is defined in the header <stdfloat> and names such a type,
the macro __STDCPP_BFLOAT16_T__ is defined, and the floating-point literal
suffixes bf16 and BF16 are supported."
because we don't really support those right now.

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

	PR c++/106652
	PR c++/85518
gcc/
	* tree-core.h (enum tree_index): Add TI_FLOAT128T_TYPE
	enumerator.
	* tree.h (float128t_type_node): Define.
	* tree.cc (build_common_tree_nodes): Initialize float128t_type_node.
	* builtins.def (DEF_FLOATN_BUILTIN): Adjust comment now that
	_Float<N> is supported in C++ too.
	* config/i386/i386.cc (ix86_mangle_type): Only mangle as "g"
	float128t_type_node.
	* config/i386/i386-builtins.cc (ix86_init_builtin_types): Use
	float128t_type_node for __float128 instead of float128_type_node
	and create it if NULL.
	* config/i386/avx512fp16intrin.h (_mm_setzero_ph, _mm256_setzero_ph,
	_mm512_setzero_ph, _mm_set_sh, _mm_load_sh): Use 0.0f16 instead of
	0.0f.
	* config/ia64/ia64.cc (ia64_init_builtins): Use
	float128t_type_node for __float128 instead of float128_type_node
	and create it if NULL.
	* config/rs6000/rs6000-c.cc (is_float128_p): Also return true
	for float128t_type_node if non-NULL.
	* config/rs6000/rs6000.cc (rs6000_mangle_type): Don't mangle
	float128_type_node as "u9__ieee128".
	* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Use
	float128t_type_node for __float128 instead of float128_type_node
	and create it if NULL.
gcc/c-family/
	* c-common.cc (c_common_reswords): Change _Float{16,32,64,128} and
	_Float{32,64,128}x flags from D_CONLY to 0.
	(shorten_binary_op): Punt if common_type returns error_mark_node.
	(shorten_compare): Likewise.
	(c_common_nodes_and_builtins): For C++ record _Float{16,32,64,128}
	and _Float{32,64,128}x builtin types if available.  For C++
	clear float128t_type_node.
	* c-cppbuiltin.cc (c_cpp_builtins): Predefine
	__STDCPP_FLOAT{16,32,64,128}_T__ for C++23 if supported.
	* c-lex.cc (interpret_float): For q/Q suffixes prefer
	float128t_type_node over float128_type_node.  Allow
	{f,F}{16,32,64,128} suffixes for C++ if supported with pedwarn
	for C++20 and older.  Allow {f,F}{32,64,128}x suffixes for C++
	with pedwarn.  Don't call excess_precision_type for C++.
gcc/cp/
	* cp-tree.h (cp_compare_floating_point_conversion_ranks): Implement
	P1467R9 - Extended floating-point types and standard names except
	for std::bfloat16_t for now.  Declare.
	(extended_float_type_p): New inline function.
	* mangle.cc (write_builtin_type): Mangle float{16,32,64,128}_type_node
	as DF{16,32,64,128}_.  Mangle float{32,64,128}x_type_node as
	DF{32,64,128}x.  Remove FIXED_POINT_TYPE mangling that conflicts
	with that.
	* typeck2.cc (check_narrowing): If one of ftype or type is extended
	floating-point type, compare floating-point conversion ranks.
	* parser.cc (cp_keyword_starts_decl_specifier_p): Handle
	CASE_RID_FLOATN_NX.
	(cp_parser_simple_type_specifier): Likewise and diagnose missing
	_Float<N> or _Float<N>x support if not supported by target.
	* typeck.cc (cp_compare_floating_point_conversion_ranks): New function.
	(cp_common_type): If both types are REAL_TYPE and one or both are
	extended floating-point types, select common type based on comparison
	of floating-point conversion ranks and subranks.
	(cp_build_binary_op): Diagnose operation with floating point arguments
	with unordered conversion ranks.
	* call.cc (standard_conversion): For floating-point conversion, if
	either from or to are extended floating-point types, set conv->bad_p
	for implicit conversion from larger to smaller conversion rank or
	with unordered conversion ranks.
	(convert_like_internal): Emit a pedwarn on such conversions.
	(build_conditional_expr): Diagnose operation with floating point
	arguments with unordered conversion ranks.
	(convert_arg_to_ellipsis): Don't promote extended floating-point types
	narrower than double to double.
	(compare_ics): Implement P1467R9 [over.ics.rank]/4 changes.
gcc/testsuite/
	* g++.dg/cpp23/ext-floating1.C: New test.
	* g++.dg/cpp23/ext-floating2.C: New test.
	* g++.dg/cpp23/ext-floating3.C: New test.
	* g++.dg/cpp23/ext-floating4.C: New test.
	* g++.dg/cpp23/ext-floating5.C: New test.
	* g++.dg/cpp23/ext-floating6.C: New test.
	* g++.dg/cpp23/ext-floating7.C: New test.
	* g++.dg/cpp23/ext-floating8.C: New test.
	* g++.dg/cpp23/ext-floating9.C: New test.
	* g++.dg/cpp23/ext-floating10.C: New test.
	* g++.dg/cpp23/ext-floating.h: New file.
	* g++.target/i386/float16-1.C: Adjust expected diagnostics.
libcpp/
	* expr.cc (interpret_float_suffix): Allow {f,F}{16,32,64,128} and
	{f,F}{32,64,128}x suffixes for C++.
include/
	* demangle.h (enum demangle_component_type): Add
	DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
	(struct demangle_component): Add u.s_extended_builtin member.
libiberty/
	* cp-demangle.c (d_dump): Handle
	DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Don't handle
	DEMANGLE_COMPONENT_FIXED_TYPE.
	(d_make_extended_builtin_type): New function.
	(cplus_demangle_builtin_types): Add _Float entry.
	(cplus_demangle_type): For DF demangle it as _Float<N> or
	_Float<N>x rather than fixed point which conflicts with it.
	(d_count_templates_scopes): Handle
	DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Just break; for
	DEMANGLE_COMPONENT_FIXED_TYPE.
	(d_find_pack): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
	Don't handle DEMANGLE_COMPONENT_FIXED_TYPE.
	(d_print_comp_inner): Likewise.
	* cp-demangle.h (D_BUILTIN_TYPE_COUNT): Bump.
	* testsuite/demangle-expected: Replace _Z3xxxDFyuVb test
	with _Z3xxxDF16_DF32_DF64_DF128_CDF16_Vb.  Add
	_Z3xxxDF32xDF64xDF128xCDF32xVb test.
fixincludes/
	* inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
	glibc_cxx_floatn_3): New fixes.
	* tests/base/bits/floatn.h: New file.
	* fixincl.x: Regenerated.