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.

GCC 14.1 is being released, retargeting bugs to GCC 14.2.

GCC 14.2 is being released, retargeting bugs to GCC 14.3.

GCC 14.3 is being released, retargeting bugs to GCC 14.4.

(In reply to Jan-Benedict Glaw from comment #14)
> Still observable as of a8994014041:

In the meantime `kernel/kallsyms.o` produced fine for gcc-15-20250406 ([1]) and Linux 6.15-rc1 for ia64.

```
time make -j24 LOCALVERSION="-25428722c4d8-ia64-w-gcc-15-20250406" ARCH=ia64 CROSS_COMPILE=ia64-linux- all
[...]
  AR      drivers/cdrom/built-in.a
  CC      kernel/kallsyms.o
  CC [M]  drivers/cdrom/cdrom.o
[...]
```

[1]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b39d5fad621c25812fb764e3a8808bab3f2fe774

****

Also Sergei's test code from [2] does compile with gcc-15-20240623 and gcc-16-20250810:

```
$ /opt/gcc-16-20250810-nolibc/ia64-linux/bin/ia64-linux-gcc -O2 -c feat.c -o bug.o  -Wall
feat.c: In function 'dccp_feat_signal_nn_change_feat':
feat.c:39:17: warning: 'entry_0' may be used uninitialized [-Wmaybe-uninitialized]
   39 |     if (entry_0 == dccp_feat_list_lookup_feat_num &&
      |         ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
feat.c:35:8: note: 'entry_0' was declared here
   35 |   char entry_0;
      |        ^~~~~~~

$ /opt/gcc-16-20250810-nolibc/ia64-linux/bin/ia64-linux-gcc -O3 -c feat.c -o bug.o  -Wall
<DITO>

$ /opt/gcc-15-20240623-nolibc/ia64-linux/bin/ia64-linux-gcc -O2 -c feat.c -o bug.o  -Wall
<DITO>

$ /opt/gcc-15-20240623-nolibc/ia64-linux/bin/ia64-linux-gcc -O3 -c feat.c -o bug.o  -Wall
<DITO>
```

[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281#c12

I don't know what gcc command line is needed to reproduce Joseph's test, but if the other tests are testing for the same issue, the problem seems to be gone or latent again.

--enable-checking=yes at least

(In reply to Sam James from comment #21)
> --enable-checking=yes at least

For Sergei's testcase using `--enable-checking=yes,rtl,tree` for gcc-16-20250810  doesn't change the outcome to before:

```
$ /opt/gcc-16-20250810-checking-yrt-nolibc/ia64-linux/bin/ia64-linux-gcc -O2 -c feat.c -o bug.o  -Wall
feat.c: In function 'dccp_feat_signal_nn_change_feat':
feat.c:39:17: warning: 'entry_0' may be used uninitialized [-Wmaybe-uninitialized]
   39 |     if (entry_0 == dccp_feat_list_lookup_feat_num &&
      |         ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
feat.c:35:8: note: 'entry_0' was declared here
   35 |   char entry_0;
      |        ^~~~~~~

$ /opt/gcc-16-20250810-checking-yrt-nolibc/ia64-linux/bin/ia64-linux-gcc -O2 -c feat.c -o bug.o  -Wall
<DITO>
```

Now compiling Linux v6.17-rc1 with this one to see its effect...

Yeah, still there for `kernel/kallsyms.c`:

```
time make -j8 LOCALVERSION="-778304a12-ia64-for-pr87281" ARCH=ia64 CROSS_COMPILE=ia64-linux- all
[...]
kernel/kallsyms.c: In function 'kallsyms_lookup_names':
kernel/kallsyms.c:219:1: error: qsort comparator non-negative on sorted output: 13
  219 | }
      | ^
during RTL pass: mach
kernel/kallsyms.c:219:1: internal compiler error: qsort checking failed
0x1eb71d1 internal_error(char const*, ...)
	/usr/src/gcc/gcc/diagnostic-global-context.cc:534
0x94a98f qsort_chk_error
	/usr/src/gcc/gcc/vec.cc:272
0x94ab44 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*, void*), void*)
	/usr/src/gcc/gcc/vec.cc:314
0x1f4a755 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*))
	/usr/src/gcc/gcc/sort.cc:272
  AR      lib/zlib_inflate/built-in.a
0x1ce0162 ready_sort_real
	/usr/src/gcc/gcc/haifa-sched.cc:3115
0x1ce8c31 ready_sort
	/usr/src/gcc/gcc/haifa-sched.cc:3131
0x1ce8c31 schedule_block(basic_block_def**, void*)
	/usr/src/gcc/gcc/haifa-sched.cc:6738
0x1dc6bbb schedule_ebb(rtx_insn*, rtx_insn*, bool)
	/usr/src/gcc/gcc/sched-ebb.cc:536
0x1dc72e0 schedule_ebbs()
	/usr/src/gcc/gcc/sched-ebb.cc:655
  CC      drivers/video/fbdev/core/fb_cmdline.o
0x15232cb ia64_reorg
	/usr/src/gcc/gcc/config/ia64/ia64.cc:9873
0x10755a9 execute
	/usr/src/gcc/gcc/reorg.cc:3924
Please submit a full bug report, with preprocessed source (by using -freport-bug).
[...]
```

Though in reality seems to not hurt operation of kernels - built with a GCC with just `--checking=release` - like the v6.17-rc1 with which my rx2800 i2 recently bootstrapped and testsuite-tested GCC 15.2.0 for 10+ hours combined. The lab room is still cooling down... ;-)

Also I wonder how many kernels are build-tested with that much checking in the compiler (i.e. `yes,rtl,tree`). Is this the rule or the exception?

(In reply to Frank Scheiner from comment #24)
> Also I wonder how many kernels are build-tested with that much checking in
> the compiler (i.e. `yes,rtl,tree`). Is this the rule or the exception?

--enable-checking=yes,extra is the default for non-released compilers unless you override it with --enable-checking=release. I build thousands of packages (and their testsuites, and then use the result for real) with --enable-checking=yes,extra,rtl.

(In reply to Sam James from comment #25)
> --enable-checking=yes,extra is the default for non-released compilers unless
> you override it with --enable-checking=release. I build thousands of
> packages (and their testsuites, and then use the result for real) with
> --enable-checking=yes,extra,rtl.

That's what I wanted to know, thanks for clarification. Can this checking in the compiler then be switched off for a kernel build (or specific files only)? Because obviously an ia64 kernel can't be built successfully with a GCC made with `--enable-checking=yes,extra,rtl`.

(In reply to Frank Scheiner from comment #26)
> (In reply to Sam James from comment #25)
> > --enable-checking=yes,extra is the default for non-released compilers unless
> > you override it with --enable-checking=release. I build thousands of
> > packages (and their testsuites, and then use the result for real) with
> > --enable-checking=yes,extra,rtl.
> 
> That's what I wanted to know, thanks for clarification. Can this checking in
> the compiler then be switched off for a kernel build (or specific files
> only)? Because obviously an ia64 kernel can't be built successfully with a
> GCC made with `--enable-checking=yes,extra,rtl`.

You can do -fno-checking to disable some bits at runtime. If that isn't enough for this case, you may want to drop the calls to qsort_chk or stub it out.