gcc-8.0.0-alpha20180211 snapshot (r257571) ICEs when compiling the following snippet w/ -O2 -fsched2-use-superblocks -ftree-parallelize-loops=2 -fno-sched-critical-path-heuristic -fno-tree-dce --param tracer-min-branch-probability=49: int zq, h9; void m0 (unsigned long int sc) { zq = 0; if (sc == 0 && h9 == 0) for (sc = 0; sc < 200; ++sc) { } } % gcc-8.0.0-alpha20180211 -O2 -fsched2-use-superblocks -ftree-parallelize-loops=2 -fno-sched-critical-path-heuristic -fno-tree-dce --param tracer-min-branch-probability=49 -c nx05nihn.c nx05nihn.c: In function 'm0': nx05nihn.c:12:1: error: qsort comparator non-negative on sorted output: 1 } ^ during RTL pass: sched2 nx05nihn.c:12:1: internal compiler error: qsort checking failed 0x7428bc qsort_chk_error /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/vec.c:201 0x742923 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/vec.c:253 0x1479810 ready_sort_real /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/haifa-sched.c:3086 0x14818e4 schedule_block(basic_block_def**, void*) /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/haifa-sched.c:6674 0x150681b schedule_ebb(rtx_insn*, rtx_insn*, bool) /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-ebb.c:537 0x1506ee4 schedule_ebbs() /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-ebb.c:657 0xc4c294 rest_of_handle_sched2 /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-rgn.c:3735 0xc4c294 execute /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180211/work/gcc-8-20180211/gcc/sched-rgn.c:3873
Confirmed, triggered in r255357 which is i386 generic tuning. Thus it was latent.
Isn't this dup of the many other qsort checking issues in the scheduler? The scheduler qsort comparator is not valid comparator in many ways.
GCC 8.1 has been released.
GCC 8.2 has been released.
Do we actually care about these now that we have gcc_qsort?
I think gcc_qsort doesn't really change things here, validation failure implies a logic issue in the comparator, so some step is not always working as the author intended. And even with gcc_qsort it's still an ice-checking (possibly on valid code). I guess evidently people don't worry too much about currently open qsort_chk bugs, but it doesn't make sense that with gcc_qsort we should care even less.
I thought the main argument for the qsort checking was to avoid different code generation between different hosts (e.g. with cross-compilers etc.). Some of the comparator issues were just easy bugs in the logic, but others are not really easily convertible to what the checking requires, it is just a heuristic to get reasonable code generation (especially some of the RTL ones). The argument about different code generation is gone with gcc_qsort.
GCC 8.3 has been released.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
Note this was not fixed by r8-6634.
*** Bug 100978 has been marked as a duplicate of this bug. ***
*** Bug 103834 has been marked as a duplicate of this bug. ***
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Just found this issue with GCC 13 (g:2dc5d6b1e7e) building the Linux kernel for ia64 (--target=ia64-linux, with eg. the zx1_defconfig): [mk all 2022-12-20 12:06:38] 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-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 [mk all 2022-12-20 12:06:40] kernel/kallsyms.c: In function 'kallsyms_lookup_names': [mk all 2022-12-20 12:06:40] kernel/kallsyms.c:268:1: error: qsort comparator non-negative on sorted output: 7 [mk all 2022-12-20 12:06:40] 268 | } [mk all 2022-12-20 12:06:40] | ^ [mk all 2022-12-20 12:06:40] during RTL pass: mach [mk all 2022-12-20 12:06:40] kernel/kallsyms.c:268:1: internal compiler error: qsort checking failed [mk all 2022-12-20 12:06:40] 0x17f0fa6 internal_error(char const*, ...) [mk all 2022-12-20 12:06:40] ???:0 [mk all 2022-12-20 12:06:40] 0x1823ee5 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) [mk all 2022-12-20 12:06:40] ???:0 [mk all 2022-12-20 12:06:40] 0x163c9a7 schedule_block(basic_block_def**, void*) [mk all 2022-12-20 12:06:40] ???:0 [mk all 2022-12-20 12:06:40] 0x171beb0 schedule_ebb(rtx_insn*, rtx_insn*, bool) [mk all 2022-12-20 12:06:40] ???:0 [mk all 2022-12-20 12:06:40] 0x171c4a9 schedule_ebbs() [mk all 2022-12-20 12:06:40] ???:0 [mk all 2022-12-20 12:06:40] Please submit a full bug report, with preprocessed source (by using -freport-bug). [mk all 2022-12-20 12:06:40] Please include the complete backtrace with any bug report. [mk all 2022-12-20 12:06:40] See <https://gcc.gnu.org/bugs/> for instructions. [mk all 2022-12-20 12:06:41] make[2]: *** [scripts/Makefile.build:250: kernel/kallsyms.o] Error 1
(In reply to Jan-Benedict Glaw from comment #17) > Just found this issue with GCC 13 (g:2dc5d6b1e7e) building the Linux kernel > for ia64 (--target=ia64-linux, with eg. the zx1_defconfig): That is a different issue, See PR 87281 and PR 90282 for the IA64 issues dealing with that.
As to comment#7 I agree, for some qsort comparators we probably do not care if the outcome is really sorted in the end and the issue with different qsort implementations producing differently sorted results is gone. Maybe for those we should have a separately named entry, skipping the verification? gcc_heuristic_sort_nocheck ()?
GCC 10 branch is being closed.