[Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

            Bug ID: 107059
           Summary: [13 regression] bootstrap failure after
                    r13-2887-gb04208895fed34
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b04208895fed34171eac6bafb60c90048eb1cb0c, r13-2887-gb04208895fed34 

Which doing a bootstrap (during stage 1) I get the following sorts of errors
after this commit.

/bin/bash ../libtool --tag CXX --tag disable-shared   --mode=compile
/home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
   -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++   -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates  -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2  -fdiagnostics-show-location=once    -ffunction-sections
-fdata-sections  -frandom-seed=atexit_thread.lo -mno-gnu-attribute -g -O2
-D_GNU_SOURCE  -c -o atexit_thread.lo
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc
libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=atexit_thread.lo -mno-gnu-attribute -g -O2 -D_GNU_SOURCE -c
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc  -fPIC
-DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
/usr/include/powerpc64le-linux-gnu/bits/floatn.h:79:9: error: multiple types in
one declaration
   79 | typedef __float128 _Float128;
      |         ^~~~~~~~~~
In file included from /usr/include/stdlib.h:56,
                 from
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:79,
                 from
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc:25:
/usr/include/powerpc64le-linux-gnu/bits/floatn.h:79:20: error: declaration does
not declare anything [-fpermissive]
   79 | typedef __float128 _Float128;
      |                    ^~~~~~~~~
In file included from /usr/include/powerpc64le-linux-gnu/bits/floatn.h:120:
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:214:9: error: multiple
types in one declaration
  214 | typedef float _Float32;
      |         ^~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:214:15: error:
declaration does not declare anything [-fpermissive]
  214 | typedef float _Float32;
      |               ^~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:251:9: error: multiple
types in one declaration
  251 | typedef double _Float64;
      |         ^~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:251:16: error:
declaration does not declare anything [-fpermissive]
  251 | typedef double _Float64;
      |                ^~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:268:9: error: multiple
types in one declaration
  268 | typedef double _Float32x;
      |         ^~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:268:16: error:
declaration does not declare anything [-fpermissive]
  268 | typedef double _Float32x;
      |                ^~~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:298:9: error: multiple
types in one declaration
  298 | typedef _Float128 _Float64x;
      |         ^~~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:298:19: error:
declaration does not declare anything [-fpermissive]
  298 | typedef _Float128 _Float64x;
      |                   ^~~~~~~~~


commit b04208895fed34171eac6bafb60c90048eb1cb0c (HEAD)
Author: Jakub Jelinek <jakub@redhat.com>
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]

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This should be fixed by r13-2896-gb939a5cc4143908ddda4b85a848c313136ff6e0c

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-09-27
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> This should be fixed by r13-2896-gb939a5cc4143908ddda4b85a848c313136ff6e0c

I still see the problem with r13-2901-g0b2706ac0e6d6b on ppc64le-linux-gnu.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With fixincludes enabled?  If yes, has bits/floatn.h and bits/floatn-common.h
been fixincluded?  The #c0 case is clearly a Debian-like setup that should have
been fixed with r13-2896

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #4 from seurer at gcc dot gnu.org ---
It still fails for me (r13-2903-ge73d9fcafbd07b).  It looks like fixincludes
ran:


make
. . .
Fixing directory /usr/include into
/home/seurer/gcc/git/build/gcc-test/gcc/include-fixed
Applying io_quotes_use            to mtd/ubi-user.h
. . .
Applying io_quotes_use            to drm/nouveau_drm.h
Applying ctrl_quotes_def          to readline/chardefs.h
Fixing directory /usr/include/clang/12/include into
/home/seurer/gcc/git/build/gcc-test/gcc/include-fixed/root/usr/lib/llvm-12/lib/clang/12.0.1/include
Cleaning up unneeded directories:
fixincludes is done

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Does it include the
Applying glibc_cxx_floatn_1       to bits/floatn.h
Applying glibc_cxx_floatn_2       to bits/floatn.h
Applying glibc_cxx_floatn_3       to bits/floatn.h
Fixed:  bits/floatn.h
Applying glibc_cxx_floatn_1       to bits/floatn-common.h
Applying glibc_cxx_floatn_2       to bits/floatn-common.h
Applying glibc_cxx_floatn_3       to bits/floatn-common.h
Fixed:  bits/floatn-common.h
parts?
Can you attach your bits/floatn{,-common.h} ?

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #6 from seurer at gcc dot gnu.org ---
Oops, I cut too much from my previous comment:

Applying glibc_cxx_floatn_1       to powerpc64le-linux-gnu/bits/floatn-common.h
Applying glibc_cxx_floatn_2       to powerpc64le-linux-gnu/bits/floatn-common.h
Applying glibc_cxx_floatn_3       to powerpc64le-linux-gnu/bits/floatn-common.h
Fixed:  powerpc64le-linux-gnu/bits/floatn-common.h
Applying glibc_cxx_floatn_1       to powerpc64le-linux-gnu/bits/floatn.h
Fixed:  powerpc64le-linux-gnu/bits/floatn.h

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, do the fixincluded headers still contain any problematic typedefs or do you
get the errors in the system versions thereof rather than the fixincluded ones?

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #8 from seurer at gcc dot gnu.org ---
The errors are all still as shown above in the same files.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Do you use some env vars to override the include paths (on IRC somebody
mentioned CPATH)?
Would be nice to rerun the failing command line in verbose mode where it would
print the include path sequence.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #10 from seurer at gcc dot gnu.org ---
No special env vars for anything on that system.  With verbose:

seurer@perkins:~/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++$
/bin/bash ../libtool --tag CXX --tag disable-shared   --mode=compile
/home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
   -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++   -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates  -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2  -fdiagnostics-show-location=once    -ffunction-sections
-fdata-sections  -frandom-seed=atexit_thread.lo -mno-gnu-attribute -g -O2
-D_GNU_SOURCE  -c -o atexit_thread.lo
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc --verbose
libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=atexit_thread.lo -mno-gnu-attribute -g -O2 -D_GNU_SOURCE -c
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc --verbose
 -fPIC -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
Reading specs from /home/seurer/gcc/git/build/gcc-test/./gcc/specs
COLLECT_GCC=/home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/seurer/gcc/git/gcc-test/configure
--prefix=/home/seurer/gcc/git/install/gcc-test --enable-languages=c,fortran,c++
--with-cpu=power9 --disable-bootstrap --disable-multilib
--with-as=/home/seurer/binutils/install/bin/as
--with-ld=/home/seurer/binutils/install/bin/ld
--with-ar=/home/seurer/binutils/install/bin/ar
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220927 (experimental) [remotes/origin/HEAD
r13-2903-ge73d9fcafb] (GCC) 
COLLECT_GCC_OPTIONS='-shared-libgcc' '-B'
'/home/seurer/gcc/git/build/gcc-test/./gcc' '-nostdinc++'
'-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src'
'-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs'
'-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs'
'-B' '/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/'
'-B' '/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/'
'-isystem'
'/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include'
'-isystem'
'/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include'
'-I' '/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc' '-I'
'/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu'
'-I'
'/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include'
'-I' '/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++' '-D'
'_GLIBCXX_SHARED' '-fno-implicit-templates' '-Wall' '-Wextra' '-Wwrite-strings'
'-Wcast-qual' '-Wabi=2' '-fdiagnostics-show-location=once'
'-ffunction-sections' '-fdata-sections' '-frandom-seed=atexit_thread.lo'
'-mno-gnu-attribute' '-g' '-O2' '-D' '_GNU_SOURCE' '-c' '-v' '-fPIC' '-D' 'PIC'
'-D' '_GLIBCXX_SHARED' '-o' 'atexit_thread.o' '-mcpu=power9'
 /home/seurer/gcc/git/build/gcc-test/./gcc/cc1plus -quiet -nostdinc++ -v -I
/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc -I
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I /home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -imultiarch
powerpc64le-linux-gnu -iprefix
/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/
-isystem /home/seurer/gcc/git/build/gcc-test/./gcc/include -isystem
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed -D_GNU_SOURCE -D
_GLIBCXX_SHARED -D _GNU_SOURCE -D PIC -D _GLIBCXX_SHARED -isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc -quiet
-dumpbase atexit_thread.cc -dumpbase-ext .cc -mno-gnu-attribute -mcpu=power9 -g
-O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -version
-fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=atexit_thread.lo -fPIC -o /tmp/ccuRtYKv.s
GNU C++17 (GCC) version 13.0.0 20220927 (experimental) [remotes/origin/HEAD
r13-2903-ge73d9fcafb] (powerpc64le-unknown-linux-gnu)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include"
ignoring nonexistent directory
"/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/../../../../powerpc64le-unknown-linux-gnu/include"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/../../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include"
ignoring nonexistent directory "/usr/local/include/powerpc64le-linux-gnu"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/../../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed"
ignoring nonexistent directory
"/home/seurer/gcc/git/build/gcc-test/gcc/../lib/gcc/../../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/../../../../powerpc64le-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc

/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 /home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
 /home/seurer/gcc/git/build/gcc-test/./gcc/include
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
End of search list.
GNU C++17 (GCC) version 13.0.0 20220927 (experimental) [remotes/origin/HEAD
r13-2903-ge73d9fcafb] (powerpc64le-unknown-linux-gnu)
        compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6288648dfe84813cea920185393e0788
/usr/include/powerpc64le-linux-gnu/bits/floatn.h:79:9: error: multiple types in
one declaration
   79 | typedef __float128 _Float128;
      |         ^~~~~~~~~~
In file included from /usr/include/stdlib.h:56,
                 from
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:79,
                 from
/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++/atexit_thread.cc:25:
/usr/include/powerpc64le-linux-gnu/bits/floatn.h:79:20: error: declaration does
not declare anything [-fpermissive]
   79 | typedef __float128 _Float128;
      |                    ^~~~~~~~~
In file included from /usr/include/powerpc64le-linux-gnu/bits/floatn.h:120:
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:214:9: error: multiple
types in one declaration
  214 | typedef float _Float32;
      |         ^~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:214:15: error:
declaration does not declare anything [-fpermissive]
  214 | typedef float _Float32;
      |               ^~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:251:9: error: multiple
types in one declaration
  251 | typedef double _Float64;
      |         ^~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:251:16: error:
declaration does not declare anything [-fpermissive]
  251 | typedef double _Float64;
      |                ^~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:268:9: error: multiple
types in one declaration
  268 | typedef double _Float32x;
      |         ^~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:268:16: error:
declaration does not declare anything [-fpermissive]
  268 | typedef double _Float32x;
      |                ^~~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:298:9: error: multiple
types in one declaration
  298 | typedef _Float128 _Float64x;
      |         ^~~~~~~~~
/usr/include/powerpc64le-linux-gnu/bits/floatn-common.h:298:19: error:
declaration does not declare anything [-fpermissive]
  298 | typedef _Float128 _Float64x;
      |                   ^~~~~~~~~

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> #include "..." search starts here:
> #include <...> search starts here:
>  /home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
>  /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-
> v3/include/powerpc64le-unknown-linux-gnu
>  /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-
> v3/include
>  /home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
>  /home/seurer/gcc/git/build/gcc-test/./gcc/include
>  /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
>  /usr/local/include
>  /usr/include/powerpc64le-linux-gnu
>  /usr/include

Strange, but above /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
comes before /usr/include/powerpc64le-linux-gnu and from what I can see at
least in my glibc headers, there is just #include <bits/floatn.h> and #include
<bits/floatn-common.h> rather than #include_next or something similar, so it is
unclear why it would pick /usr/include/powerpc64le-linux-gnu/bits/floatn.h
rather than
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/bits/floatn.h

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org
               Host|powerpc64le-linux-gnu       |powerpc64le-linux-gnu,
                   |                            |aarch64-linux-gnu
             Target|powerpc64le-linux-gnu       |powerpc64le-linux-gnu,
                   |                            |aarch64-linux-gnu
              Build|powerpc64le-linux-gnu       |powerpc64le-linux-gnu,
                   |                            |aarch64-linux-gnu

--- Comment #12 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
I have the same problem, no special flags nothing. but bootstrap and
non-bootstrap are still broken.

In file included from /usr/include/stdlib.h:55,
                 from
/opt/buildAgent/temp/buildTmp/aarch64-unknown-linux-gnu/libstdc++-v3/include/cstdlib:79,
                 from
/opt/buildAgent/work/5c94c4ced6ebfcd0/libstdc++-v3/libsupc++/del_op.cc:38:
/usr/include/aarch64-linux-gnu/bits/floatn.h:80:14: error: multiple types in
one declaration
   80 | typedef long double _Float128;

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I wonder how it works for Tobias then.
If the fixincluded headers go to
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn{,-common}.h
and search path is:
...
 /home/seurer/gcc/git/build/gcc-test/./gcc/include
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
then I think it can't find those headers for #include <bits/floatn.h>
Given the above, I think the search paths should be:
...
 /home/seurer/gcc/git/build/gcc-test/./gcc/include
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu
 /home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
because the multiarch subdir sits below /usr/include and so is fixincluded
together with it.  I'd be afraid we fixinclude all the other arches if they
are, so if one has
/usr/include/powerpc64le-linux-gnu/bits/floatn.h
/usr/include/x86_64-linux-gnu/bits/floatn.h
both would go to:
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn.h
/home/seurer/gcc/git/build/gcc-test/./gcc/include-fixed/x86_64-linux-gnu/bits/floatn.h
so making fixincludes itself multiarch aware is going to be difficult.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
cppdefault.cc has:
#ifdef FIXED_INCLUDE_DIR
    /* This is the dir for fixincludes.  */
    { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
      /* A multilib suffix needs adding if different multilibs use
         different headers.  */
#ifdef SYSROOT_HEADERS_SUFFIX_SPEC
      1
#else
      0
#endif
    },
#endif
...
#ifdef NATIVE_SYSTEM_HEADER_DIR
    /* /usr/include comes dead last.  */
    { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
    { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
where that 2 in the last column of the penultimate entry is what I think adds
for multi-arch the multiarch suffixes to /usr/include and 1 in the penultimate
column says to prefix that with sysroot.
So, I wonder if we don't want a
    { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, 2 },
entry somewhere.  SYSROOT_HEADERS_SUFFIX_SPEC is defined I think on vxworks and
mti-linux, neither of which can be multiarch, so I think we could do:
--- gcc/cppdefault.cc.jj        2022-01-18 11:58:59.411984500 +0100
+++ gcc/cppdefault.cc   2022-09-28 12:11:47.923603783 +0200
@@ -74,6 +74,9 @@ const struct default_include cpp_include
 #endif
 #ifdef FIXED_INCLUDE_DIR
     /* This is the dir for fixincludes.  */
+#ifndef SYSROOT_HEADERS_SUFFIX_SPEC
+    { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0, 2 },
+#endif
     { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
       /* A multilib suffix needs adding if different multilibs use
         different headers.  */

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> I wonder how it works for Tobias then.

Bootstrap
* works on x86_64  with Ubuntu 20.04.5 LTS (focal) with glibc 2.31-0ubuntu9.9
* fails on ppc64le  with Ubuntu 18.04.3 LTS (bionic) with glibc 2.27-3ubuntu1

I have now done some debugging. The reason it works on x86-64 is that I have
there
in the $BUILD directory:
  gcc/include-fixed/bits -> x86_64-linux-gnu/bits

That matches:
  /usr/include/bits -> x86_64-linux-gnu/bits 

dpkg -S find
* the symbolic link in package libc6-dev-i386
* the real 'bits' directory in package libc6-dev:amd64


On PowerPC, I see /usr/include/powerpc64le-linux-gnu/bits but no associated
/usr/include/bits symbolic link. (The existing directory is in package
libc6-dev:ppc64el)

 * * *

Before finding this, I wondered whether --enable-multiarch makes a difference,
but it doesn't.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> ..., so I think we could do:
> --- gcc/cppdefault.cc.jj	2022-01-18 11:58:59.411984500 +0100
> +++ gcc/cppdefault.cc	2022-09-28 12:11:47.923603783 +0200

It tried this now on ppc64le with Ubuntu 18.04.3 LTS (bionic) with glibc
2.27-3ubuntu1
and - because I have used it last - with --enable-multiarch.

However, it still fails. According to strace, it searches:

/tmp/tburnus-gcc-test/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/.
/tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed/.
/tmp/tburnus-gcc-test/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/powerpc64le-linux-gnu

but not
  /tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu

A solution would be
  target=powerpc64le-linux-gnu
  cd $BUILD/gcc
  if [[ -d include-fixed/$target ]]; then
    mkdir $target;
    ln -s include-fixed/$target $target/include-fixed
  fi
or something similar in the fix-include machinery.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #16)
>     ln -s include-fixed/$target $target/include-fixed

That should have been:
  ln -s ../include-fixed/$target $target/include-fixed

with that change, ./gcc/xgcc -v -B`pwd`/gcc foo.c  works and shows:

#include "..." search starts here:
#include <...> search starts here:
 /tmp/tburnus-gcc-test/gcc/include
 /tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed
 /tmp/tburnus-gcc-test/gcc/include-fixed
 /usr/local/include
 /usr/include/powerpc64le-linux-gnu
 /usr/include
End of search list.
...
# 30 "/usr/include/complex.h" 2 3 4
# 1
"/tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed/bits/floatn.h" 1
3 4

and when continuing the bootstrap build, it now successfully finished with
Stage 1 and I am positive that it will also finish building Stage 2 + 3.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You mean the #c14 change incorrectly adds
/tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed
rather than
/tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu
to search path?

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #19 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #18)
> You mean the #c14
comment 14 (< this adds a link)

> change incorrectly adds
>   /tmp/tburnus-gcc-test/gcc/powerpc64le-linux-gnu/include-fixed
> rather than
>   /tmp/tburnus-gcc-test/gcc/include-fixed/powerpc64le-linux-gnu
> to search path?

Maybe. Or rather: Yes, for the *being* *build* compiler (with "xgcc -B
$BUILD/gcc")
it *either* adds the wrong directory
*or* fixinclude creates the wrong directory.

However, for the *installed* compiler, we have:

#include "..." search starts here:
#include <...> search starts here:

/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include
 /usr/local/include
 /tmp/tburnus-gcc-test-inst/include

/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/powerpc64le-linux-gnu

/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed
 /usr/include/powerpc64le-linux-gnu
 /usr/include
End of search list.

And as the fix-include floatn.h is under
/tmp/tburnus-gcc-test-inst/lib/gcc/powerpc64le-unknown-linux-gnu/13.0.0/include-fixed/powerpc64le-linux-gnu/bits/floatn.h

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #19)
> However, for the *installed* compiler, we have:
...
> And as the fix-include floatn.h is under
...

(To finish the sentence: Thus,)

the *installed* compiler *finds* the fixed-include fixed header file,
contrary to the being build compiler.

A quick testing (delete 'bits' symlink on x86-64) shows that that's due to the
patch from comment 14 - as x86-64 otherwise uses
/usr/include/x86-64*/bits/floatn.h.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #19)
Ah, so it is then correct for the installed compiler and we just need to figure
out where the search paths for the build compiler come from and how they are
determined.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Even with the fixincluded headers properly being used, the powerpc64le 
issue still applies because of the issue I noted in 
https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
with certain required changes to the powerpc version of bits/floatn.h not 
being covered by the fixincludes fixes added.  You get errors such as:

/scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/include-fixed/bits/floatn.h:88:9:
error: multiple types in one declaration
   88 | typedef __float128 _Float128;
      |         ^~~~~~~~~~

while building libstdc++.  (Whereas other architectures can build GCC OK 
but then run into failures building glibc that my glibc patch is intended 
to address.)

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #23 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Regarding the $BUILD/gcc/include-fixed and xgcc -B $BUILD/gcc:

In gcc.cc's driver_handle_option:

        add_prefix (&include_prefixes, arg, NULL,
                    PREFIX_PRIORITY_B_OPT, 0, 0);
Adds "$BUILD/gcc/" to the prefix list in include_prefix.plist (priority =
PREFIX_PRIORITY_B_OPT, require_machine_suffix = os_multilib = 0)
the include_prefixes.name is "include".

This is later processed in do_spec_1 as:
              info.option = "-isystem";
              info.append = "include";
...
              for_each_path (&include_prefixes, false, info.append_len,
                             spec_path, &info);
...
              info.append = "include-fixed";
              for_each_path (&include_prefixes, false, info.append_len,
                             spec_path, &info);
which in turn runs with (<prefix> = "$BUILD/gcc/"):

  <prefix>/x86_64-pc-linux-gnu/13.0.0/
  <prefix>/x86_64-linux-gnu/
  <prefix>

It also sets -iprefix $BUILD/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/
             -isystem $BUILD/gcc/{include,include-fixed}

Without -B, include_prefix.plist is NULL and also no -iprefix is set. Thus, cc1
has to find the paths itself. – The iprefix does not really matter, except that
with the installed compiler, the include-fixed can be found at
  <prefix>/include-fixed
which is $INSTALL/lib/gcc/$target/13.0.0/include-fixed
and is part of the 'cpp_include_defaults' array.

With the in-build compiler,  $BUILD/lib/gcc/$target/13.0.0/include-fixed
is checked for - but does not exist.


The additionally specified -isystem is processed - but not under the multiarch
processing. 

 * * *

Thus, one possibility that should work as well is to create the include-fixed
not under gcc/ but under lib/gcc/$target/$version/include-fixed

Or to change the   for_each_path + spec_path such that it puts "include-fixed'
between
plist->name and the multiarch and then uses "" as suffix (alias info.append)

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #22)
> Even with the fixincluded headers properly being used, the powerpc64le 
> issue still applies because of the issue I noted in 
> https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
> with certain required changes to the powerpc version of bits/floatn.h not 
> being covered by the fixincludes fixes added.  You get errors such as:
> 
> /scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/
> include-fixed/bits/floatn.h:88:9: error: multiple types in one declaration
>    88 | typedef __float128 _Float128;
>       |         ^~~~~~~~~~
> 
> while building libstdc++.  (Whereas other architectures can build GCC OK 
> but then run into failures building glibc that my glibc patch is intended 
> to address.)

Posted patch for this in
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #25 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #22)
> with certain required changes to the powerpc version of bits/floatn.h not 
> being covered by the fixincludes fixes added.

Jakub has posted a patch for this one:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html

(Side note: As I have glibc 2.27 on PowerPC and the "#   if __LDBL_MANT_DIG__
== 113"
change went into 2.28, the pattern matching did work here.)

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #23)
> Regarding the $BUILD/gcc/include-fixed and xgcc -B $BUILD/gcc:
> 
> In gcc.cc's driver_handle_option:
> 
>         add_prefix (&include_prefixes, arg, NULL,
>                     PREFIX_PRIORITY_B_OPT, 0, 0);
> Adds "$BUILD/gcc/" to the prefix list in include_prefix.plist (priority =
> PREFIX_PRIORITY_B_OPT, require_machine_suffix = os_multilib = 0)
> the include_prefixes.name is "include".
> 
> This is later processed in do_spec_1 as:
>               info.option = "-isystem";
>               info.append = "include";
> ...
>               for_each_path (&include_prefixes, false, info.append_len,
>                              spec_path, &info);
> ...
>               info.append = "include-fixed";
>               for_each_path (&include_prefixes, false, info.append_len,
>                              spec_path, &info);
> which in turn runs with (<prefix> = "$BUILD/gcc/"):
>   
>   <prefix>/x86_64-pc-linux-gnu/13.0.0/
>   <prefix>/x86_64-linux-gnu/
>   <prefix>
> 
> It also sets -iprefix $BUILD/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/
>              -isystem $BUILD/gcc/{include,include-fixed}

Well, the upper directories to include/include-fixed should stay as they are,
that is how to find the include-fixed directory.
But for multi-arch we need to search both include-fixed/<multiarch_dir>
and include-fixed, so I think we need in addition to the comment 14 patch
also (completely untested):
--- gcc/gcc.cc  2022-09-23 09:02:56.809314447 +0200
+++ gcc/gcc.cc  2022-09-28 21:02:29.751933657 +0200
@@ -6400,6 +6400,18 @@ do_spec_1 (const char *spec, int inswitc
              if (*sysroot_hdrs_suffix_spec)
                info.append = concat (info.append, dir_separator_str,
                                      multilib_dir, NULL);
+             else if (multiarch_dir)
+               {
+                 /* For multiarch, search include-fixed/<multiarch-dir>
+                    before include-fixed.  */
+                 info.append = concat (info.append, dir_separator_str,
+                                       multiarch_dir, NULL);
+                 info.append_len = strlen (info.append);
+                 for_each_path (&include_prefixes, false, info.append_len,
+                                spec_path, &info);
+
+                 info.append = "include-fixed";
+               }
              info.append_len = strlen (info.append);
              for_each_path (&include_prefixes, false, info.append_len,
                             spec_path, &info);
It is roughly what the comment 14 patch does, just in a different spot.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[manuel.lauss at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #27 from Manuel Lauss <manuel.lauss at googlemail dot com> ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to joseph@codesourcery.com from comment #22)
> > Even with the fixincluded headers properly being used, the powerpc64le 
> > issue still applies because of the issue I noted in 
> > https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
> > with certain required changes to the powerpc version of bits/floatn.h not 
> > being covered by the fixincludes fixes added.  You get errors such as:
> > 
> > /scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/
> > include-fixed/bits/floatn.h:88:9: error: multiple types in one declaration
> >    88 | typedef __float128 _Float128;
> >       |         ^~~~~~~~~~
> > 
> > while building libstdc++.  (Whereas other architectures can build GCC OK 
> > but then run into failures building glibc that my glibc patch is intended 
> > to address.)
> 
> Posted patch for this in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html

for me the x86-64 build remains broken the same way as the ppc64 build.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #28 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a5a9237e2a78a9854f1f87e63ef5619cf8ba7360

commit r13-2932-ga5a9237e2a78a9854f1f87e63ef5619cf8ba7360
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Sep 29 12:04:24 2022 +0200

    driver, cppdefault: Unbreak bootstrap on Debian/Ubuntu [PR107059]

    My recent change to enable _Float{16,32,64,128,32x,64x,128x} for C++
    apparently broke bootstrap on some Debian/Ubuntu setups.
    Those multiarch targets put some headers into
    /usr/include/x86_64-linux-gnu/bits/ etc. subdirectory instead of
    /usr/include/bits/.
    This is handled by
        /* /usr/include comes dead last.  */
        { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2
},
        { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0
},
    in cppdefault.cc, where the 2 in the last element of the first initializer
    means the entry is ignored on non-multiarch and suffixed by the multiarch
    dir otherwise, so installed gcc has search path like:
    
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include
    
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed
     /usr/local/include
     /usr/include/x86_64-linux-gnu
     /usr/include
    (when installed with DESTDIR=/home/jakub/gcc/obj01inst).
    Now, when fixincludes is run, it is processing the whole /usr/include dir
    and all its subdirectories, so floatn{,-common.h} actually go into
    .../include-fixed/x86_64-linux-gnu/bits/floatn{,-common.h}
    because that is where they appear in /usr/include too.
    In some setups, /usr/include also contains /usr/include/bits ->
x86_64-linux-gnu/bits
    symlink and after the r13-2896 tweak it works.
    In other setups there is no /usr/include/bits symlink and when one
     #include <bits/floatn.h>
    given the above search path, it doesn't find the fixincluded header,
    as
   
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/bits/floatn.h
    doesn't exist and
   
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu/bits/floatn.h
    isn't searched and so
    /usr/include/x86_64-linux-gnu/bits/floatn.h
    wins and we fail because of typedef whatever _Float128; and similar.
    The following patch ought to fix this.  The first hunk by arranging that
    the installed search path actually looks like:
    
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include
    
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu
    
/home/jakub/gcc/obj01inst/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/include-fixed
     /usr/local/include
     /usr/include/x86_64-linux-gnu
     /usr/include
    and thus for include-fixed it treats it the same as /usr/include.
    The second FIXED_INCLUDE_DIR entry there is:
         { FIXED_INCLUDE_DIR, "GCC", 0, 0, 0,
           /* A multilib suffix needs adding if different multilibs use
              different headers.  */
     #ifdef SYSROOT_HEADERS_SUFFIX_SPEC
           1
     #else
           0
     #endif
         },
    where SYSROOT_HEADERS_SUFFIX_SPEC is defined only on vxworks or
mips*-mti-linux
    and arranges for multilib path to be appended there.  Neither of those
    systems is multiarch.
    This isn't enough, because when using the -B option, the driver adds
    -isystem .../include-fixed in another place, so the second hunk modifies
    that spot the same.
    /home/jakub/gcc/obj01/gcc/xgcc -B /home/jakub/gcc/obj01/gcc/
    then has search path:
     /home/jakub/gcc/obj01/gcc/include
     /home/jakub/gcc/obj01/gcc/include-fixed/x86_64-linux-gnu
     /home/jakub/gcc/obj01/gcc/include-fixed
     /usr/local/include
     /usr/include/x86_64-linux-gnu
     /usr/include
    which again is what I think we want to achieve.

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

            PR bootstrap/107059
            * cppdefault.cc (cpp_include_defaults): If
SYSROOT_HEADERS_SUFFIX_SPEC
            isn't defined, add FIXED_INCLUDE_DIR entry with multilib flag 2
            before FIXED_INCLUDE_DIR entry with multilib flag 0.
            * gcc.cc (do_spec_1): If multiarch_dir, add
            include-fixed/multiarch_dir paths before include-fixed paths.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602431.html
still awaits review, the rest should be fixed.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #30 from seurer at gcc dot gnu.org ---
Any more progress on this?  Builds still fail on powerpc64 LE.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Still waiting for review.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:62ec780ac0b4d109f2a3c8c4597cb19a82f6188d

commit r13-3147-g62ec780ac0b4d109f2a3c8c4597cb19a82f6188d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Oct 7 08:56:04 2022 +0200

    fixincludes: Fix up powerpc floatn.h tweaks [PR107059]

    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.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #33 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:348e46fa8cba960c23170673bfc0c1b4fb384975

commit r13-3148-g348e46fa8cba960c23170673bfc0c1b4fb384975
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Oct 7 08:59:05 2022 +0200

    fixincludes: Deal also with the _Float128x cases [PR107059]

    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.

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.