| Summary: | [14 Regression] qsort checking ICE in ia64_reorg building libgo | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Joseph S. Myers <jsm28> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | ebotcazou, jbglaw, sjames, slyfox, wilson |
| Priority: | P4 | Keywords: | build, ice-checking, ice-on-valid-code |
| Version: | 9.0 | ||
| Target Milestone: | 14.0 | ||
| See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90282 | ||
| Host: | Target: | ia64-*-* | |
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2023-11-02 00:00:00 | |
| Bug Depends on: | |||
| Bug Blocks: | 82407 | ||
| Attachments: | Test that started failing on 20 July 2023 | ||
|
Description
Joseph S. Myers
2018-09-11 11:40:19 UTC
Probably a dup of the various scheduler related qsort ICEs. Does this still show up in 9.1? No idea. I ran all-languages builds for all glibc ABIs as a one-off when adding the --full-gcc option to build-many-glibcs.py, and reported the GCC bugs that showed up. The idea was that since maintainers of such language libraries (and of libsanitizer) had concerns about glibc header changes sometimes breaking the build of those libraries, I'd provide the facility in build-many-glibcs.py for people with those concerns to run a bot testing them with current glibc, in order to detect problems quickly rather than only after an issue gets into a glibc release. But I was definitely leaving it up to people with such concerns to deal with running the bot, and I don't think anyone has taken up doing so. As of r272229 I can't replicate this: $ ~/glibc/scripts/build-many-glibcs.py bmg --full-gcc compilers ia64-linux-gnu PASS: compilers-ia64-linux-gnu check-host-libraries ... PASS: compilers-ia64-linux-gnu done > As of r272229 I can't replicate this:
>
> $ ~/glibc/scripts/build-many-glibcs.py bmg --full-gcc compilers
> ia64-linux-gnu
> PASS: compilers-ia64-linux-gnu check-host-libraries
> ...
> PASS: compilers-ia64-linux-gnu done
Note that you need to test the trunk in order to get the diagnostics, or else to configure the 9.x compiler with --enable-checking=release,misc at least.
(In reply to Eric Botcazou from comment #5) > Note that you need to test the trunk in order to get the diagnostics, or > else to configure the 9.x compiler with --enable-checking=release,misc at > least. I don't understand how that applies in the context of Joseph's build-many-glibcs.py script. > I don't understand how that applies in the context of Joseph's
> build-many-glibcs.py script.
This PR is about a compiler issue so I presume that build-many-glibcs.py tests the compiler at some point? If so, then you either need to make sure that it tests the trunk compiler and not the compiler from the 9 branch, or else you need to configure the compiler from the 9 branch with --enable-checking=release,misc.
(In reply to Joseph S. Myers from comment #0) > Building an all-languages cross compiler for ia64-linux-gnu, trunk r264193, > I see the following ICE building libgo > bytes.go:211:1: internal compiler error: qsort checking failed I could certainly be misunderstanding this, but as libgo is part of the compiler, I believe this would show up while building the cross compiler without any additional settings, configuration, or testing: (edited for (hopeful) clarity) libtool: compile: build/build/compilers/ia64-linux-gnu/gcc/./gcc/gccgo -Bbuild/build/compilers/ia64-linux-gnu/gcc/./gcc/ -Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/bin/ -Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/ -isystem build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/include -isystem build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/sys-include -O2 -g -I . -c -fgo-pkgpath=bytes build/src/gcc/libgo/go/bytes/buffer.go build/src/gcc/libgo/go/bytes/bytes.go build/src/gcc/libgo/go/bytes/reader.go -o bytes.o >/dev/null 2>&1 libtool: link: build/build/compilers/ia64-linux-gnu/gcc/./gcc/xgcc -Bbuild/build/compilers/ia64-linux-gnu/gcc/./gcc/ -Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/bin/ -Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/ -isystem build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/include -isystem build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/sys-include -shared [...] .libs/bytes.o [...] -Wl,--whole-archive ../libbacktrace/.libs/libbacktrace.a ../libatomic/.libs/libatomic_convenience.a ../libffi/.libs/libffi_convenience.a -Wl,--no-whole-archive -Lbuild/build/compilers/ia64-linux-gnu/gcc/ia64-glibc-linux-gnu/libatomic/.libs -lpthread -lm -pthread -pthread -Wl,-soname -Wl,libgo.so.14 -o .libs/libgo.so.14.0.0 lrwxrwxrwx 1 jason jason 15 Jun 14 09:48 build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/libgo.so.14 -> libgo.so.14.0.0 -rwxr-xr-x 1 jason jason 61070664 Jun 14 09:48 build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/libgo.so.14.0.0 When using "build-many-glibcs <dir> checkout" to check out the source tree, you need to specify "gcc-vcs-mainline" after "checkout" to get GCC trunk sources checked out instead of the default of GCC 9 branch. (I assume I don't need to run build-libraries again...) $ ~/glibc/scripts/build-many-glibcs.py --replace-sources bmg checkout gcc-vcs-mainline configure.ac:80: installing 'build-aux/compile' configure.ac:46: installing 'build-aux/config.guess' configure.ac:46: installing 'build-aux/config.sub' configure.ac:26: installing 'build-aux/install-sh' configure.ac:26: installing 'build-aux/missing' Makefile.am: installing './INSTALL' Makefile.am: installing 'build-aux/depcomp' Makefile.am:32: installing 'build-aux/mdate-sh' doc/Makefrag.am:106: warning: user target '$(srcdir)/doc/version.texi' defined here ... Makefile.am:155: 'doc/Makefrag.am' included from here /usr/share/automake-1.16/am/texi-vers.am: ... overrides Automake target '$(srcdir)/doc/version.texi' defined here Makefile.am:32: installing 'build-aux/texinfo.tex' parallel-tests: installing 'build-aux/test-driver' configure.ac:25: installing 'build-aux/compile' configure.ac:9: installing 'build-aux/config.guess' configure.ac:9: installing 'build-aux/config.sub' configure.ac:14: installing 'build-aux/install-sh' configure.ac:14: installing 'build-aux/missing' Makefile.am: installing './INSTALL' Makefile.am: installing 'build-aux/depcomp' configure.ac: installing 'build-aux/ylwrap' parallel-tests: installing 'build-aux/test-driver' $ ~/glibc/scripts/build-many-glibcs.py --full-gcc bmg compilers ia64-linux-gnu PASS: compilers-ia64-linux-gnu check-host-libraries PASS: compilers-ia64-linux-gnu binutils rm PASS: compilers-ia64-linux-gnu binutils mkdir PASS: compilers-ia64-linux-gnu binutils configure PASS: compilers-ia64-linux-gnu binutils build PASS: compilers-ia64-linux-gnu binutils install PASS: compilers-ia64-linux-gnu binutils cleanup PASS: compilers-ia64-linux-gnu linux rm PASS: compilers-ia64-linux-gnu linux mkdir PASS: compilers-ia64-linux-gnu linux install-headers PASS: compilers-ia64-linux-gnu linux cleanup PASS: compilers-ia64-linux-gnu gcc-first rm PASS: compilers-ia64-linux-gnu gcc-first mkdir PASS: compilers-ia64-linux-gnu gcc-first configure PASS: compilers-ia64-linux-gnu gcc-first build PASS: compilers-ia64-linux-gnu gcc-first install PASS: compilers-ia64-linux-gnu gcc-first cleanup PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu rm PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu mkdir PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu configure PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu build PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu install PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu mkdir-lib PASS: compilers-ia64-linux-gnu glibc ia64-linux-gnu cleanup PASS: compilers-ia64-linux-gnu gcc rm PASS: compilers-ia64-linux-gnu gcc mkdir PASS: compilers-ia64-linux-gnu gcc configure PASS: compilers-ia64-linux-gnu gcc build PASS: compilers-ia64-linux-gnu gcc install PASS: compilers-ia64-linux-gnu gcc cleanup PASS: compilers-ia64-linux-gnu done $ *** Bug 106616 has been marked as a duplicate of this bug. *** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106616#c0 provides hopefully reproducible test. GCC 13 (as of g:02c031088ac0bbf) triggers this for Linux's kallsys.c (f9ff5644bcc04221bae56f922) for ia64. Still observable as of a8994014041:
[...]
ia64-linux-gcc -Wp,-MMD,kernel/.kallsyms.o.d -nostdinc -I./arch/ia64/include -I./arch/ia64/include/generated -I./include -I./arch/ia64/include/uapi -I./arch/ia64/include/generated/uapi -I.
/include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -funsigned-char -std=gnu11 -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -frename-registers -fno-optimize-sibling-calls -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fno-stack-protector -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -falign-functions=32 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-array-bounds -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -mconstant-gp -DKBUILD_MODFILE='"kernel/kallsyms"' -DKBUILD_BASENAME='"kallsyms"' -DKBUILD_MODNAME='"kallsyms"' -D__KBUILD_MODNAME=kmod_kallsyms -c -o kernel/kallsyms.o kernel/kallsyms.c
kernel/kallsyms.c: In function 'kallsyms_lookup_names':
kernel/kallsyms.c:268:1: error: qsort comparator non-negative on sorted output: 1
268 | }
| ^
during RTL pass: mach
kernel/kallsyms.c:268:1: internal compiler error: qsort checking failed
0x188b086 internal_error(char const*, ...)
???:0
0x18bf855 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*))
???:0
0x15c7a08 schedule_block(basic_block_def**, void*)
???:0
0x1685c1b schedule_ebb(rtx_insn*, rtx_insn*, bool)
???:0
0x168622d schedule_ebbs()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [scripts/Makefile.build:252: kernel/kallsyms.o] Error 1
make[1]: *** [scripts/Makefile.build:494: kernel] Error 2
make: *** [Makefile:2026: .] Error 2
Created attachment 56496 [details] Test that started failing on 20 July 2023 Another instance of this ICE appeared in my glibc bot on 20 July; compile ibm1008_420.i with -O2. This failure was introduced by commit ef28aadad6e5cff3d7494f3c97d435a6579a2e2d Author: Jan Hubicka <jh@suse.cz> Date: Thu Jul 20 15:41:39 2023 +0200 loop-ch improvements, part 3 although I fully expect it's really the same bug as for the other testcases discussed here and it was just some perturbation to the processing of this test that resulted in the appearance for that test with that commit. The issue is surely latent for long, not sure if that "new" trigger warrants to make it a 14 regression. Anyway, ia64 -> P4. |