Summary: | [12/13/14/15 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1) | ||
---|---|---|---|
Product: | gcc | Reporter: | Arseny Solokha <asolokha> |
Component: | rtl-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | amonakov, jakub, jbglaw, zsojka |
Priority: | P2 | Keywords: | ice-checking, ice-on-valid-code |
Version: | 8.0 | ||
Target Milestone: | 12.5 | ||
See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83631 |
||
Host: | Target: | x86_64-unknown-linux-gnu | |
Build: | Known to work: | 7.3.0 | |
Known to fail: | 8.0 | Last reconfirmed: | 2018-02-13 00:00:00 |
Bug Depends on: | |||
Bug Blocks: | 82407 |
Description
Arseny Solokha
2018-02-12 18:24:35 UTC
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. GCC 11 branch is being closed. |