I suspect r14-4339-geaa41a6dc127d8 "Remove poly_int_pod" caused checking build failure as: In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480, from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22: /home/slyfox/dev/git/gcc/gcc/poly-int.h: In instantiation of ‘constexpr poly_int<N, T>::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int}; unsigned int N = 1; C = long int]’: /home/slyfox/dev/git/gcc/gcc/poly-int.h:439:13: required from here /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long int>(1, 1)’ /home/slyfox/dev/git/gcc/gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’ 453 | : coeffs { (typename poly_coeff_traits<C>:: | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 454 | template init_cast<Cs>::type (cs))... } {} | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ make[3]: *** [Makefile:1188: rtl-tests.o] Error 1 To reproduce: $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc -O1 -g0' CXX='g++ -O1 -g0' $ make -j16 profiledbootstrap $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -v Reading specs from /tmp/gb/./prev-gcc/specs COLLECT_GCC=/tmp/gb/./prev-gcc/xg++ COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ CC='gcc -O1 -g0' CXX='g++ -O1 -g0' Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230929 (experimental) (GCC)
Looks like this code is all under `#if CHECKING_P` of sorts. A few more possibly affected entries: ``` $ git grep -P 'poly_int64 \(\d+, \d+\)' gcc/config/riscv/riscv-selftests.cc: -BYTES_PER_RISCV_VECTOR * 33, poly_int64 (207, 0), gcc/config/riscv/riscv-selftests.cc: poly_int64 (-207, 0), poly_int64 (0, 207), gcc/config/riscv/riscv-selftests.cc: poly_int64 (0, -207), poly_int64 (5555, 0), gcc/config/riscv/riscv-selftests.cc: poly_int64 (0, 5555), poly_int64 (4096, 4096), gcc/config/riscv/riscv-selftests.cc: poly_int64 (17, 4088), poly_int64 (3889, 4104), gcc/config/riscv/riscv-selftests.cc: poly_int64 (9317, -88), poly_int64 (4, 4), gcc/config/riscv/riscv-selftests.cc: poly_int64 (17, 4), poly_int64 (-7337, 4), gcc/config/riscv/riscv-selftests.cc: poly_int64 (219, -1508), poly_int64 (2, 2), gcc/config/riscv/riscv-selftests.cc: poly_int64 (33, 2), poly_int64 (-7337, 2), gcc/config/riscv/riscv-selftests.cc: poly_int64 (945, -954), poly_int64 (1, 1), gcc/config/riscv/riscv-selftests.cc: poly_int64 (977, 1), poly_int64 (-339, 1), gcc/config/riscv/riscv-selftests.cc: poly_int64 (44, -1), poly_int64 (9567, 77), gcc/config/riscv/riscv.cc: return poly_int64 (1, 1); gcc/rtl-tests.cc: rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); gcc/rtl-tests.cc: rtx x255 = gen_int_mode (poly_int64 (1, 255), QImode); gcc/rtl-tests.cc: ASSERT_EQ (x1, gen_int_mode (poly_int64 (1, 1), QImode)); gcc/rtl-tests.cc: ASSERT_NE (x1, gen_int_mode (poly_int64 (1, 1), HImode)); gcc/rtl-tests.cc: ASSERT_KNOWN_EQ (const_poly_int_value (x1), poly_int64 (1, 1)); gcc/rtl-tests.cc: ASSERT_KNOWN_EQ (rtx_to_poly_int64 (x1), poly_int64 (1, 1)); gcc/rtl-tests.cc: ASSERT_MAYBE_NE (rtx_to_poly_int64 (x255), poly_int64 (1, 255)); gcc/rtl-tests.cc: rtx offset1 = gen_int_mode (poly_int64 (9, 11), Pmode); gcc/rtl-tests.cc: ASSERT_RTX_EQ (plus_constant (Pmode, symbol, poly_int64 (9, 11)), sum1); gcc/rtl-tests.cc: rtx offset2 = gen_int_mode (poly_int64 (12, 20), Pmode); gcc/rtl-tests.cc: ASSERT_RTX_EQ (plus_constant (Pmode, sum1, poly_int64 (3, 9)), sum2); gcc/simplify-rtx.cc: rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); gcc/simplify-rtx.cc: rtx x4 = gen_int_mode (poly_int64 (5, 4), QImode); gcc/simplify-rtx.cc: rtx x5 = gen_int_mode (poly_int64 (30, 24), QImode); gcc/simplify-rtx.cc: rtx x6 = gen_int_mode (poly_int64 (20, 16), QImode); gcc/simplify-rtx.cc: rtx x7 = gen_int_mode (poly_int64 (7, 4), QImode); gcc/simplify-rtx.cc: rtx x8 = gen_int_mode (poly_int64 (30, 24), HImode); ```
Just hit the one in simplify-rtx.cc on Linux/sparc64: In file included from /var/tmp/portage/sys-devel/gcc-14.0.0.9999/work/gcc-14.0.0.9999/gcc/coretypes.h:480, from /var/tmp/portage/sys-devel/gcc-14.0.0.9999/work/gcc-14.0.0.9999/gcc/simplify-rtx.cc:23: /var/tmp/portage/sys-devel/gcc-14.0.0.9999/work/gcc-14.0.0.9999/gcc/poly-int.h: In instantiation of ‘constexpr poly_int<N, T>::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int}; unsigned int N = 1; C = long int]’: /var/tmp/portage/sys-devel/gcc-14.0.0.9999/work/gcc-14.0.0.9999/gcc/poly-int.h:439:13: required from here /var/tmp/portage/sys-devel/gcc-14.0.0.9999/work/gcc-14.0.0.9999/gcc/simplify-rtx.cc:8692:25: in ‘constexpr’ expansion of ‘poly_int<1, long int>(1, 1)’ /var/tmp/portage/sys-devel/gcc-14.0.0.9999/work/gcc-14.0.0.9999/gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’ 453 | : coeffs { (typename poly_coeff_traits<C>:: | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 454 | template init_cast<Cs>::type (cs))... } {} | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(In reply to Sergei Trofimovich from comment #0) > To reproduce: > > $ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++ > CC='gcc -O1 -g0' CXX='g++ -O1 -g0' > $ make -j16 profiledbootstrap Minor note: it has something to do with 4-stage bootstrap (which profiledbootstrap also happens to be). `make bootstrap4` fails the same way.
Looks like `-fchecking=1` and `-fno-checking` handle c++ a bit differently. Two commands differing only in `-fno-checking`. One works, one does not: ``` $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o rtl-tests.o -MT rtl-tests.o -MMD -MP -MF ./.deps/rtl-tests.TPo /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480, from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22: /home/slyfox/dev/git/gcc/gcc/poly-int.h: In instantiation of 'constexpr poly_int<N, T>::poly_int(poly_int_full, const Cs& ...) [with Cs = {int, int}; unsigned int N = 1; C = long int]': /home/slyfox/dev/git/gcc/gcc/poly-int.h:439:13: required from here /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:25: in 'constexpr' expansion of 'poly_int<1, long int>(1, 1)' /home/slyfox/dev/git/gcc/gcc/poly-int.h:453:5: error: too many initializers for 'long int [1]' 453 | : coeffs { (typename poly_coeff_traits<C>:: | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 454 | template init_cast<Cs>::type (cs))... } {} | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # fails ``` ``` $ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/gb/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -fno-PIE -I. -I. -I/home/slyfox/dev/git/gcc/gcc -I/home/slyfox/dev/git/gcc/gcc/. -I/home/slyfox/dev/git/gcc/gcc/../include -I/home/slyfox/dev/git/gcc/gcc/../libcpp/include -I/home/slyfox/dev/git/gcc/gcc/../libcody -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/slyfox/dev/git/gcc/gcc/../libbacktrace -o rtl-tests.o -MT rtl-tests.o -MMD -MP -MF ./.deps/rtl-tests.TPo /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc -fno-checking # ok ```
The default value is `-fchecking=2` there. `-fchecking=0` and `-fchecking=1` work fine. This means `-fchecking=` slightly alters c++ template instantiation. I'll try to extract smaller example. The following workaround seems to restore the build: --- a/gcc/cp/pt.cc +++ b/gcc/cp/pt.cc @@ -29302,20 +29302,21 @@ tree build_non_dependent_expr (tree expr) { tree orig_expr = expr; tree inner_expr; /* When checking, try to get a constant value for all non-dependent expressions in order to expose bugs in *_dependent_expression_p and constexpr. This can affect code generation, see PR70704, so only do this for -fchecking=2. */ if (flag_checking > 1 + && false && cxx_dialect >= cxx11 /* Don't do this during nsdmi parsing as it can lead to unexpected recursive instantiations. */ && !parsing_nsdmi () /* Don't do this during concept processing either and for the same reason. */ && !processing_constraint_expression_p ()) fold_non_dependent_expr (expr, tf_none); STRIP_ANY_LOCATION_WRAPPER (expr);
(In reply to Sergei Trofimovich from comment #5) > I'll try to extract smaller example. Got the following, but I'm not sure it's valid C++: struct poly_int { template <typename...> constexpr poly_int() : poly_int() {} }; template <int> void run() { poly_int(); } Filed PR111647 and will try to extract something less invalid.
If I try to build the file with `clang++-16` I'm getting the following error: In file included from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22: In file included from /home/slyfox/dev/git/gcc/gcc/coretypes.h:480: /home/slyfox/dev/git/gcc/gcc/poly-int.h:453:14: error: excess elements in array initializer : coeffs { (typename poly_coeff_traits<C>:: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/slyfox/dev/git/gcc/gcc/poly-int.h:438:5: note: in instantiation of function template specialization 'poly_int<1, long>::poly_int<int, int>' requested here : poly_int (typename poly_int_fullness<sizeof... (Cs) >= N>::type (), ^ /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:249:26: note: in instantiation of function template specialization 'poly_int<1, long>::poly_int<int, int>' requested here rtx x1 = gen_int_mode (poly_int64 (1, 1), QImode); ^ Which sounds like we should not try to create polynomials with values more than `NUM_POLY_INT_COEFFS` (== 1 on x86_64). I'm still not sure if the templates are expected to defer build failure in this case or it's a c++ syntax error in gcc's code.
With https://gcc.gnu.org/PR111647#c1 I'm convinced it's a gcc's source code bug and we should not try to write calls like `poly_int<1, T>(1, 1)` with mismatching arity.
interestingly, I reproduced this with '../gcc/configure --enable-languages=d --disable-bootstrap' so, perhaps it's not just bootstrap4 that fails (though, my host GCC is 13.. will try a 14 snapshot in a moment..)
ah, yeah, seems that the common thread is checking. my system compiler is built with --enable-checking=yes,extra,rtl. 'make -j17 CXXFLAGS=-fno-checking' also seems to work around it
Proposed the possible fix as https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631739.html It #ifdefs out any attempts to create multi-coefficient polynomials on the system with a single polynomial like `poly_int<1, T>(1, 1)`.
*** Bug 111656 has been marked as a duplicate of this bug. ***
Created attachment 56023 [details] Tentative fix Sorry for the radio silence, had a network outage. I'm testing the attached, which if it works would avoid resorting to the preprocessor.
(In reply to Richard Sandiford from comment #13) > Created attachment 56023 [details] > Tentative fix Re " That now triggers a warning in some configurations, since the NUM_POLY_INT_COEFFS>1 tests used the global poly_int64, whose definition does not depend on the template parameter." Minor note: it's a type error for clang++ and g++ -fchecking=2, not just a warning. I think both gcc and clang do reject the code as they see a type mismatch in `poly_int64<1, T>(1,1)` call. Otherwise the fix works for me and passes `make bootstrap4`. Thank you!
(In reply to Richard Sandiford from comment #13) > Created attachment 56023 [details] > Tentative fix > > Sorry for the radio silence, had a network outage. I'm testing the > attached, which if it works would avoid resorting to the preprocessor. Works for me too. I ran into this issue when I tried to build GCC on a dev workstation where host GCC was configured with --enable-checking=yes,extra.
Marking it P1 as it's breaking bootstrap on various conditions.
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>: https://gcc.gnu.org/g:e465e5e4a969334f64cf0d6611de5273d73ea732 commit r14-4359-ge465e5e4a969334f64cf0d6611de5273d73ea732 Author: Richard Sandiford <richard.sandiford@arm.com> Date: Mon Oct 2 07:20:45 2023 +0100 Fix profiledbootstrap poly_int fallout [PR111642] rtl-tests.cc and simplify-rtx.cc used partial specialisation to try to restrict the NUM_POLY_INT_COEFFS>1 tests without resorting to preprocessor tests. That now triggers an error in some configurations, since the NUM_POLY_INT_COEFFS>1 tests used the global poly_int64, whose definition does not depend on the template parameter. This patch uses local types that do depend on the template parameter. gcc/ PR bootstrap/111642 * rtl-tests.cc (const_poly_int_tests<N>::run): Use a local poly_int64 typedef. * simplify-rtx.cc (simplify_const_poly_int_tests<N>::run): Likewise.
Fixed.