Bug 87281 - [14 Regression] qsort checking ICE in ia64_reorg building libgo
Summary: [14 Regression] qsort checking ICE in ia64_reorg building libgo
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 9.0
: P4 normal
Target Milestone: 14.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build, ice-checking, ice-on-valid-code
: 106616 (view as bug list)
Depends on:
Blocks: qsort_chk
  Show dependency treegraph
 
Reported: 2018-09-11 11:40 UTC by Joseph S. Myers
Modified: 2024-01-10 10:12 UTC (History)
5 users (show)

See Also:
Host:
Target: ia64-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-11-02 00:00:00


Attachments
Test that started failing on 20 July 2023 (51.21 KB, text/plain)
2023-11-02 22:36 UTC, Joseph S. Myers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph S. Myers 2018-09-11 11:40:19 UTC
Building an all-languages cross compiler for ia64-linux-gnu, trunk r264193, I see the following ICE building libgo (I don't know how to produce any equivalent of preprocessed source as a self-contained testcase for Go code, and I don't know whether this is a regression):

/scratch/jmyers/glibc/many9/src/gcc/libgo/go/bytes/bytes.go: In function 'bytes.genSplit':
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/bytes/bytes.go:211:1: error: qsort comparator non-negative on sorted output: 2
211 | func genSplit(s, sep []byte, sepSave, n int) [][]byte {
    | ^
during RTL pass: mach
/scratch/jmyers/glibc/many9/src/gcc/libgo/go/bytes/bytes.go:211:1: internal compiler error: qsort checking failed
0x7388f2 qsort_chk_error
        /scratch/jmyers/glibc/many9/src/gcc/gcc/vec.c:201
0x7389fc qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*))
        /scratch/jmyers/glibc/many9/src/gcc/gcc/vec.c:244
0x12dbde0 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*))
        /scratch/jmyers/glibc/many9/src/gcc/gcc/sort.cc:238
0x11d1b40 ready_sort_real
        /scratch/jmyers/glibc/many9/src/gcc/gcc/haifa-sched.c:3089
0x11d95ca schedule_block(basic_block_def**, void*)
        /scratch/jmyers/glibc/many9/src/gcc/gcc/haifa-sched.c:6677
0x1256575 schedule_ebb(rtx_insn*, rtx_insn*, bool)
        /scratch/jmyers/glibc/many9/src/gcc/gcc/sched-ebb.c:537
0x1256bf4 schedule_ebbs()
        /scratch/jmyers/glibc/many9/src/gcc/gcc/sched-ebb.c:657
0xf40cfc ia64_reorg
        /scratch/jmyers/glibc/many9/src/gcc/gcc/config/ia64/ia64.c:9859
0xbe42c9 execute
        /scratch/jmyers/glibc/many9/src/gcc/gcc/reorg.c:3984
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Makefile:2941: recipe for target 'bytes.lo' failed
make[5]: *** [bytes.lo] Error 1
Comment 1 Andreas Schwab 2018-09-11 12:13:17 UTC
Probably a dup of the various scheduler related qsort ICEs.
Comment 2 Jason Duerstock 2019-06-13 20:31:26 UTC
Does this still show up in 9.1?
Comment 3 jsm-csl@polyomino.org.uk 2019-06-13 22:43:54 UTC
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.
Comment 4 Jason Duerstock 2019-06-14 02:50:02 UTC
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
Comment 5 Eric Botcazou 2019-06-14 08:43:13 UTC
> 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.
Comment 6 Jason Duerstock 2019-06-14 11:06:19 UTC
(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.
Comment 7 Eric Botcazou 2019-06-14 11:39:32 UTC
> 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.
Comment 8 Jason Duerstock 2019-06-14 14:25:20 UTC
(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
Comment 9 jsm-csl@polyomino.org.uk 2019-06-17 22:12:48 UTC
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.
Comment 10 Jason Duerstock 2019-06-17 23:20:11 UTC
(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
$
Comment 11 Andrew Pinski 2022-08-14 19:08:21 UTC
*** Bug 106616 has been marked as a duplicate of this bug. ***
Comment 12 Sergei Trofimovich 2022-08-14 19:58:21 UTC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106616#c0 provides hopefully reproducible test.
Comment 13 Jan-Benedict Glaw 2022-12-20 22:21:56 UTC
GCC 13 (as of g:02c031088ac0bbf) triggers this for Linux's kallsys.c (f9ff5644bcc04221bae56f922) for ia64.
Comment 14 Jan-Benedict Glaw 2023-06-24 09:45:53 UTC
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
Comment 15 Joseph S. Myers 2023-11-02 22:36:45 UTC
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.
Comment 16 Richard Biener 2024-01-10 10:12:24 UTC
The issue is surely latent for long, not sure if that "new" trigger warrants to make it a 14 regression.  Anyway, ia64 -> P4.