* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
@ 2022-09-27 17:10 ` jakub at gcc dot gnu.org
2022-09-27 17:28 ` marxin at gcc dot gnu.org
` (33 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-27 17:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
2022-09-27 17:10 ` [Bug bootstrap/107059] " jakub at gcc dot gnu.org
@ 2022-09-27 17:28 ` marxin at gcc dot gnu.org
2022-09-27 17:37 ` jakub at gcc dot gnu.org
` (32 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-09-27 17:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
2022-09-27 17:10 ` [Bug bootstrap/107059] " jakub at gcc dot gnu.org
2022-09-27 17:28 ` marxin at gcc dot gnu.org
@ 2022-09-27 17:37 ` jakub at gcc dot gnu.org
2022-09-27 18:40 ` seurer at gcc dot gnu.org
` (31 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-27 17:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2022-09-27 17:37 ` jakub at gcc dot gnu.org
@ 2022-09-27 18:40 ` seurer at gcc dot gnu.org
2022-09-27 18:50 ` jakub at gcc dot gnu.org
` (30 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: seurer at gcc dot gnu.org @ 2022-09-27 18:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2022-09-27 18:40 ` seurer at gcc dot gnu.org
@ 2022-09-27 18:50 ` jakub at gcc dot gnu.org
2022-09-27 18:52 ` seurer at gcc dot gnu.org
` (29 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-27 18:50 UTC (permalink / raw)
To: gcc-bugs
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} ?
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2022-09-27 18:50 ` jakub at gcc dot gnu.org
@ 2022-09-27 18:52 ` seurer at gcc dot gnu.org
2022-09-27 19:13 ` jakub at gcc dot gnu.org
` (28 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: seurer at gcc dot gnu.org @ 2022-09-27 18:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2022-09-27 18:52 ` seurer at gcc dot gnu.org
@ 2022-09-27 19:13 ` jakub at gcc dot gnu.org
2022-09-27 19:20 ` seurer at gcc dot gnu.org
` (27 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-27 19:13 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2022-09-27 19:13 ` jakub at gcc dot gnu.org
@ 2022-09-27 19:20 ` seurer at gcc dot gnu.org
2022-09-27 19:26 ` jakub at gcc dot gnu.org
` (26 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: seurer at gcc dot gnu.org @ 2022-09-27 19:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2022-09-27 19:20 ` seurer at gcc dot gnu.org
@ 2022-09-27 19:26 ` jakub at gcc dot gnu.org
2022-09-27 19:59 ` seurer at gcc dot gnu.org
` (25 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-27 19:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2022-09-27 19:26 ` jakub at gcc dot gnu.org
@ 2022-09-27 19:59 ` seurer at gcc dot gnu.org
2022-09-27 20:22 ` jakub at gcc dot gnu.org
` (24 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: seurer at gcc dot gnu.org @ 2022-09-27 19:59 UTC (permalink / raw)
To: gcc-bugs
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;
| ^~~~~~~~~
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2022-09-27 19:59 ` seurer at gcc dot gnu.org
@ 2022-09-27 20:22 ` jakub at gcc dot gnu.org
2022-09-28 9:45 ` tnfchris at gcc dot gnu.org
` (23 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-27 20:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2022-09-27 20:22 ` jakub at gcc dot gnu.org
@ 2022-09-28 9:45 ` tnfchris at gcc dot gnu.org
2022-09-28 9:46 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2022-09-28 9:45 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2022-09-28 9:45 ` tnfchris at gcc dot gnu.org
@ 2022-09-28 9:46 ` jakub at gcc dot gnu.org
2022-09-28 10:12 ` jakub at gcc dot gnu.org
` (21 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-28 9:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (12 preceding siblings ...)
2022-09-28 9:46 ` jakub at gcc dot gnu.org
@ 2022-09-28 10:12 ` jakub at gcc dot gnu.org
2022-09-28 10:59 ` burnus at gcc dot gnu.org
` (20 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-28 10:12 UTC (permalink / raw)
To: gcc-bugs
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. */
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (13 preceding siblings ...)
2022-09-28 10:12 ` jakub at gcc dot gnu.org
@ 2022-09-28 10:59 ` burnus at gcc dot gnu.org
2022-09-28 11:18 ` burnus at gcc dot gnu.org
` (19 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 10:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (14 preceding siblings ...)
2022-09-28 10:59 ` burnus at gcc dot gnu.org
@ 2022-09-28 11:18 ` burnus at gcc dot gnu.org
2022-09-28 11:26 ` burnus at gcc dot gnu.org
` (18 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 11:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (15 preceding siblings ...)
2022-09-28 11:18 ` burnus at gcc dot gnu.org
@ 2022-09-28 11:26 ` burnus at gcc dot gnu.org
2022-09-28 11:37 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 11:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (16 preceding siblings ...)
2022-09-28 11:26 ` burnus at gcc dot gnu.org
@ 2022-09-28 11:37 ` jakub at gcc dot gnu.org
2022-09-28 12:58 ` burnus at gcc dot gnu.org
` (16 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-28 11:37 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (17 preceding siblings ...)
2022-09-28 11:37 ` jakub at gcc dot gnu.org
@ 2022-09-28 12:58 ` burnus at gcc dot gnu.org
2022-09-28 13:10 ` burnus at gcc dot gnu.org
` (15 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 12:58 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (18 preceding siblings ...)
2022-09-28 12:58 ` burnus at gcc dot gnu.org
@ 2022-09-28 13:10 ` burnus at gcc dot gnu.org
2022-09-28 13:12 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 13:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (19 preceding siblings ...)
2022-09-28 13:10 ` burnus at gcc dot gnu.org
@ 2022-09-28 13:12 ` jakub at gcc dot gnu.org
2022-09-28 17:16 ` joseph at codesourcery dot com
` (13 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-28 13:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (20 preceding siblings ...)
2022-09-28 13:12 ` jakub at gcc dot gnu.org
@ 2022-09-28 17:16 ` joseph at codesourcery dot com
2022-09-28 18:40 ` burnus at gcc dot gnu.org
` (12 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: joseph at codesourcery dot com @ 2022-09-28 17:16 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (21 preceding siblings ...)
2022-09-28 17:16 ` joseph at codesourcery dot com
@ 2022-09-28 18:40 ` burnus at gcc dot gnu.org
2022-09-28 18:47 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 18:40 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (22 preceding siblings ...)
2022-09-28 18:40 ` burnus at gcc dot gnu.org
@ 2022-09-28 18:47 ` jakub at gcc dot gnu.org
2022-09-28 18:57 ` burnus at gcc dot gnu.org
` (10 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-28 18:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (23 preceding siblings ...)
2022-09-28 18:47 ` jakub at gcc dot gnu.org
@ 2022-09-28 18:57 ` burnus at gcc dot gnu.org
2022-09-28 19:04 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: burnus at gcc dot gnu.org @ 2022-09-28 18:57 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (24 preceding siblings ...)
2022-09-28 18:57 ` burnus at gcc dot gnu.org
@ 2022-09-28 19:04 ` jakub at gcc dot gnu.org
2022-09-28 19:20 ` manuel.lauss at googlemail dot com
` (8 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-28 19:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (25 preceding siblings ...)
2022-09-28 19:04 ` jakub at gcc dot gnu.org
@ 2022-09-28 19:20 ` manuel.lauss at googlemail dot com
2022-09-29 8:07 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: manuel.lauss at googlemail dot com @ 2022-09-28 19:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (26 preceding siblings ...)
2022-09-28 19:20 ` manuel.lauss at googlemail dot com
@ 2022-09-29 8:07 ` rguenth at gcc dot gnu.org
2022-09-29 10:06 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-29 8:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (27 preceding siblings ...)
2022-09-29 8:07 ` rguenth at gcc dot gnu.org
@ 2022-09-29 10:06 ` cvs-commit at gcc dot gnu.org
2022-09-29 10:14 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-09-29 10:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (28 preceding siblings ...)
2022-09-29 10:06 ` cvs-commit at gcc dot gnu.org
@ 2022-09-29 10:14 ` jakub at gcc dot gnu.org
2022-10-03 15:29 ` seurer at gcc dot gnu.org
` (4 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-09-29 10:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (29 preceding siblings ...)
2022-09-29 10:14 ` jakub at gcc dot gnu.org
@ 2022-10-03 15:29 ` seurer at gcc dot gnu.org
2022-10-03 15:33 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: seurer at gcc dot gnu.org @ 2022-10-03 15:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (30 preceding siblings ...)
2022-10-03 15:29 ` seurer at gcc dot gnu.org
@ 2022-10-03 15:33 ` jakub at gcc dot gnu.org
2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-10-03 15:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (31 preceding siblings ...)
2022-10-03 15:33 ` jakub at gcc dot gnu.org
@ 2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org
2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org
2022-10-07 7:01 ` jakub at gcc dot gnu.org
34 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-07 7:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (32 preceding siblings ...)
2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org
@ 2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org
2022-10-07 7:01 ` jakub at gcc dot gnu.org
34 siblings, 0 replies; 36+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-07 7:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread* [Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34
2022-09-27 16:46 [Bug bootstrap/107059] New: [13 regression] bootstrap failure after r13-2887-gb04208895fed34 seurer at gcc dot gnu.org
` (33 preceding siblings ...)
2022-10-07 7:00 ` cvs-commit at gcc dot gnu.org
@ 2022-10-07 7:01 ` jakub at gcc dot gnu.org
34 siblings, 0 replies; 36+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-10-07 7:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 36+ messages in thread