GCC 9 fails to build lib/zstd/compress.c with an internal compiler error: guppy /usr/src/linux # gcc -Wp,-MD,lib/zstd/.compress.o.d -nostdinc -isystem /usr/lib/gcc/ia64-unknown-linux-gnu/9.2.0/include -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/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -DHAVE_WORKING_TEXT_ALIGN -DHAVE_MODEL_SMALL_ATTRIBUTE -DHAVE_SERIALIZE_DIRECTIVE -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -falign-functions=32 -frename-registers -fno-optimize-sibling-calls -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Wno-address-of-packed-member -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -O3 -mconstant-gp -DKBUILD_BASENAME='"compress"' -DKBUILD_MODNAME='"zstd_compress"' -c -o lib/zstd/compress.o lib/zstd/compress.c during RTL pass: mach lib/zstd/compress.c: In function ‘ZSTD_loadZstdDictionary’: lib/zstd/compress.c:2719:1: internal compiler error: in sel_target_adjust_priority, at sel-sched.c:3334 2719 | } | ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.gentoo.org/> for instructions. This has been preventing the ia64 catalyst builds from succeeding since gcc 9 was stabilized.
Probably a https://gcc.gnu.org/PR88879 (will be in 9.3).
Yep, that patch (just removing the assert) allows the kernel to build.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=066e26c95928de295cf822034de2d2cd05acf8af commit 066e26c95928de295cf822034de2d2cd05acf8af Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-02-06 19:19:13 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-02-06 19:19:30 +0000 sys-devel/gcc: allow negative insn cost, bug #707958 Apply the patch right on stable ebuild to unblock catalyst builds for ia64. Reported-by: Matt Turner Bug: https://bugs.gentoo.org/707958 Package-Manager: Portage-2.3.87, Repoman-2.3.20 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/gcc/files/gcc-9.2.0-neg-insn-cost.patch | 29 +++++++++++++++++++++++ sys-devel/gcc/gcc-9.2.0-r2.ebuild | 7 +++++- sys-devel/gcc/gcc-9.2.0-r3.ebuild | 9 ++++++- 3 files changed, 43 insertions(+), 2 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=38039a107e4ac09fc34d9433dfe2fba9a20e1b92 commit 38039a107e4ac09fc34d9433dfe2fba9a20e1b92 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-02-06 19:22:55 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-02-06 19:22:55 +0000 9.2.0: pull in PR88879 (negative insn cost), bug #707958 Single new upstream patch 34_all_ia64-neg-insn-cost.patch to allow zstd to build successfully. Reported-by: Matt Turner Closes: https://bugs.gentoo.org/707958 Bug: https://gcc.gnu.org/PR88879 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> 9.2.0/gentoo/34_all_ia64-neg-insn-cost.patch | 29 ++++++++++++++++++++++++++++ 9.2.0/gentoo/README.history | 3 +++ 2 files changed, 32 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c059facbe9af77c4f8a8c783a826e4d47ea1b267 commit c059facbe9af77c4f8a8c783a826e4d47ea1b267 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-02-15 20:10:06 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-02-15 20:13:40 +0000 sys-devel/gcc: 9.2.0: cut 5 patchset Three new patches: + 34_all_ia64-neg-insn-cost.patch: fix lz4 code generation on ia64 + 35_all_glibc-2.31-libsanitizer-{1,2}.patch: fix build against glibc-2.31 Closes: https://bugs.gentoo.org/707958 Bug: https://gcc.gnu.org/PR88879 Closes: https://bugs.gentoo.org/708346 Package-Manager: Portage-2.3.88, Repoman-2.3.20 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/gcc/Manifest | 1 + sys-devel/gcc/gcc-9.2.0-r4.ebuild | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+)
Re-opening, as I am triggering this on a mips cross-compiler kernel build using gcc-9.3.0: CC lib/win_minmax.o GEN lib/crc32table.h CC lib/xarray.o CC lib/oid_registry.o CC lib/crc32.o AR lib/lib.a EXPORTS lib/lib-ksyms.o during RTL pass: mach lib/zstd/compress.c: In function 'ZSTD_getCParams': lib/zstd/compress.c:3431:1: internal compiler error: in simplify_binary_operation, at simplify-rtx.c:2153 3431 | } | ^ 0x7f3f2d639d7a __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. make[2]: *** [scripts/Makefile.build:276: lib/zstd/compress.o] Error 1 make[1]: *** [scripts/Makefile.build:492: lib/zstd] Error 2 make: *** [Makefile:1067: lib] Error 2 # uname -a Linux helcaraxe 5.6.5 #1 SMP Sat Apr 18 14:06:10 EDT 2020 x86_64 Genuine Intel(R) CPU @ 3.40GHz GenuineIntel GNU/Linux # mips64-unknown-linux-gnu-gcc --version mips64-unknown-linux-gnu-gcc (Gentoo 9.3.0 p2) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
IA64, feel free to remove yourselves if you guys know for certain this is fixed on your platform. I have to wonder if there might be an unresolved case w/ cross-compilers that was missed.
Okay, this is gonna be weird to explain. And it's a bug in the mips kernel that the upstream guys are not gonna enjoy chasing down. For years, I've included a patch in sys-kernel/mips-sources that adds missing Makefile ifdefs into the SGI Platform files (which are just Makefiles). Specifically, arch/mips/sgi-ip32/Platform and arch/mips/sgi-ip22/Platform. Years ago, when building IP30 support at some point, I ran into some kind of error, the details of which I do not remember. Some digging around led me to conclude that IP30's build files were accidentally ingesting IP32's directives...somewhere. Adding the ifdefs to the Platformf iles fixed things, because IP27's Platform files already had them. Implying that at some point much farther back in the past, Ralf Baechle (original MIPS maintainer) must have ran into some kind of issue with IP27 possibly ingesting files from IP22. Fixing IP27 solved the case, as I assume building IP22 doesn't accidentally import IP27. So it's a bug in the upstream MIPS kernel Makefile logic of some kind. I just tried to send this patch upstream, and upstream wanted me to test building a kernel without it. So I did. And that triggers the ICE in GCC-9.3 on zstd. Initially, I did not connect the removal of the patch as being a trigger for this issue, because well, I found a fairly recent bug documenting the issue //and// fixing it. Anyways, let me hold this one open while I report back to upstream and let them scratch their heads over this.
(In reply to Joshua Kinard from comment #7) > IA64, feel free to remove yourselves if you guys know for certain this is > fixed on your platform. I have to wonder if there might be an unresolved > case w/ cross-compilers that was missed. No. You open a different bug for your different bug.
(In reply to Matt Turner from comment #9) > (In reply to Joshua Kinard from comment #7) > > IA64, feel free to remove yourselves if you guys know for certain this is > > fixed on your platform. I have to wonder if there might be an unresolved > > case w/ cross-compilers that was missed. > > No. You open a different bug for your different bug. Yeah, I confirmed it's a mips-specific thing. I wasn't sure initially and finding a bug already present for the exact issue, thought it was better to reopen this bug. Sorry for the noise!
