On Thu, May 26, 2022 at 11:02:02AM +0200, Jakub Jelinek wrote:
> On Thu, May 26, 2022 at 10:08:49AM +0200, Peter Zijlstra wrote:
> > On Thu, May 26, 2022 at 10:03:13AM +0200, Peter Zijlstra wrote:
> >
> > > Which is just bloody weird/broken if you ask me. What's worse, GCC-10
> > > does the same. Only when I use GCC-11 do I get sensible code again:
> >
> > Just to clarify, I can reproduce using:
> >
> > gcc-9 (Debian 9.4.0-5) 9.4.0
> > gcc-10 (Debian 10.3.0-15) 10.3.0
> >
> > The good compiler is:
> >
> > gcc-11 (Debian 11.3.0-1) 11.3.0
>
> Such fallthrough into another function is typically the result
> of __builtin_unreachable (), either explicit somewhere in the code,
> or invoking undefined behavior somewhere and __builtin_unreachable ()
> replacing the UB code.
> I'd need preprocessed source + full gcc command line to tell more
> (as long as it is not LTO, with LTO that isn't enough of course).
$ make O=build/ CC=gcc-9 kernel/rcu/update.o V=1
gives the compile command as:
gcc-9 -Wp,-MMD,kernel/rcu/.update.o.d -nostdinc -I../arch/x86/include -I./arch/x86/include/generated -I../include -I./include -I../arch/x86/include/uapi -I./arch/x86/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__ -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 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Werror -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -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 -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -I ../kernel/rcu -I ./kernel/rcu -DKBUILD_MODFILE='"kernel/rcu/update"' -DKBUILD_BASENAME='"update"' -DKBUILD_MODNAME='"update"' -D__KBUILD_MODNAME=kmod_update -c -o kernel/rcu/update.o ../kernel/rcu/update.c
I've attached the output of:
$ make O=build/ CC=gcc-9 kernel/rcu/update.i
On Thu, May 26, 2022 at 11:41:24AM +0200, Peter Zijlstra wrote:
> On Thu, May 26, 2022 at 11:02:02AM +0200, Jakub Jelinek wrote:
> > On Thu, May 26, 2022 at 10:08:49AM +0200, Peter Zijlstra wrote:
> > > On Thu, May 26, 2022 at 10:03:13AM +0200, Peter Zijlstra wrote:
> > >
> > > > Which is just bloody weird/broken if you ask me. What's worse, GCC-10
> > > > does the same. Only when I use GCC-11 do I get sensible code again:
> > >
> > > Just to clarify, I can reproduce using:
> > >
> > > gcc-9 (Debian 9.4.0-5) 9.4.0
> > > gcc-10 (Debian 10.3.0-15) 10.3.0
> > >
> > > The good compiler is:
> > >
> > > gcc-11 (Debian 11.3.0-1) 11.3.0
> >
> > Such fallthrough into another function is typically the result
> > of __builtin_unreachable (), either explicit somewhere in the code,
> > or invoking undefined behavior somewhere and __builtin_unreachable ()
> > replacing the UB code.
> > I'd need preprocessed source + full gcc command line to tell more
> > (as long as it is not LTO, with LTO that isn't enough of course).
>
> $ make O=build/ CC=gcc-9 kernel/rcu/update.o V=1
>
> gives the compile command as:
>
> gcc-9 -Wp,-MMD,kernel/rcu/.update.o.d -nostdinc -I../arch/x86/include -I./arch/x86/include/generated -I../include -I./include -I../arch/x86/include/uapi -I./arch/x86/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__ -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 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Werror -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-frame-pointer -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 -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -I ../kernel/rcu -I ./kernel/rcu -DKBUILD_MODFILE='"kernel/rcu/update"' -DKBUILD_BASENAME='"update"' -DKBUILD_MODNAME='"update"' -D__KBUILD_MODNAME=kmod_update -c -o kernel/rcu/update.o ../kernel/rcu/update.c
>
> I've attached the output of:
>
> $ make O=build/ CC=gcc-9 kernel/rcu/update.i
Filed https://gcc.gnu.org/PR105739 for this, the replacement
happens during inlining, so I've CCed Honza Hubicka who knows
that code best.
It is unlikely anything can be done about this for GCC 9,
because the final GCC 9.5 release is to be released tomorrow,
there is no chance of getting it fixed by then, especially
when it doesn't look like a recent regression.
Jakub
On Thu, May 26, 2022 at 01:32:19PM +0200, Jakub Jelinek wrote:
> Filed https://gcc.gnu.org/PR105739 for this, the replacement
> happens during inlining, so I've CCed Honza Hubicka who knows
> that code best.
Thanks!
> It is unlikely anything can be done about this for GCC 9,
> because the final GCC 9.5 release is to be released tomorrow,
> there is no chance of getting it fixed by then, especially
> when it doesn't look like a recent regression.
Yeah, that's unfortunate timing, nothing to be done about that though.