Hi Segher!

On Mon, 2022-12-12 18:26:13 -0600, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> On Mon, Dec 12, 2022 at 10:51:17PM +0100, Jan-Benedict Glaw wrote:
[...]
> > For PPC, a good number of those fail,
> > and I probably don't understand PPC well enough to propose patches. Or
> > did I pick wrongly targeted toolchains? Most of the time, my suspicion
> > is that we're not giving the correct -m<cpu> flags in
> > ./arch/powerpc/boot/?  (My setup for doing test builds is fairly automated, I
> > can easily throw in patches for testing.)
> 
> Many of those use a 32-bit toolchain with a 64-bit kernel, or they
> require some e500 specific config but not getting it (or the other way
> around).
> 
> > 64-bit.config
> 
> > 	==> Why "-m32 -mcpu=powerpc"? Binutils/GCC are for --target=powerpc64-linux
> 
> Something in your config is forcing that.

That's a configuration that should not have been built. As Michael
wrote, it's just a fragment for a defconfig, I queued it for a build
but that was plain wrong. (As well as other *.config files.)

> > 	Compiler ICEs (during GIMPLE pass: ccp) in align.c:
> > 
> > 	  powerpc-linux-gcc -Wp,-MMD,arch/powerpc/kernel/.align.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/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__ -I ./arch/powerpc -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 -std=gnu11 -mbig-endian -m32 -msoft-float -pipe -ffixed-r2 -mmultiple -mno-readonly-in-sdata -mcpu=440 -mno-prefixed -mno-pcrel -mno-altivec -mno-vsx -mno-mma -fno-asynchronous-unwind-tables -mno-string -Wa,-m440 -mbig-endian -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -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=1024 -fstack-protector-strong -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 -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 -g -mstack-protector-guard-offset=1080 -Werror    -DKBUILD_MODFILE='"arch/powerpc/kernel/align"' -DKBUILD_BASENAME='"align"' -DKBUILD_MODNAME='"align"' -D__KBUILD_MODNAME=kmod_align -c -o arch/powerpc/kernel/align.o arch/powerpc/kernel/align.c  
> > 	during GIMPLE pass: ccp
> > 	arch/powerpc/kernel/align.c: In function '__copy_inst_from_kernel_nofault':
> > 	arch/powerpc/kernel/align.c:364:1: internal compiler error: in maybe_register_def, at tree-into-ssa.cc:1948
> > 	  364 | }
> > 	      | ^
> > 	0x19d8886 internal_error(char const*, ...)
> > 	   ???:0
> > 	0x7bb4fe fancy_abort(char const*, int, char const*)
> > 	   ???:0
> > 	0x1791bfe dom_walker::walk(basic_block_def*)
> > 	   ???:0
> > 	0xe94ec0 update_ssa(unsigned int)
> > 	   ???:0
> > 	0x103d6b9 execute_update_addresses_taken()
> > 	   ???: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[3]: *** [scripts/Makefile.build:250: arch/powerpc/kernel/align.o] Error 1
> > 	make[2]: *** [scripts/Makefile.build:500: arch/powerpc/kernel] Error 2
> > 	make[1]: *** [scripts/Makefile.build:500: arch/powerpc] Error 2
> > 	make: *** [Makefile:1992: .] Error 2
> > 
> > 	==> Should probably open a PR for this.
> 
> Yes please!

I'll wait until the current build loop finishes. Looking at
__copy_inst_from_kernel_nofault(), it uses an asm goto, which I had
issues with and there was already a fix for it
(7676235f690e624b7ed41a22b22ce8ccfac1492f,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997) which might fix
all of those.

Thanks,
  Jan-Benedict

--