Re: arch/powerpc/math-emu/fcmpu.c:13:2: warning: variable 'A_c' set but not used

From: Nick Desaulniers
Date: Wed Jun 14 2023 - 14:52:01 EST


On Wed, Jun 14, 2023 at 2:26 PM Christophe Leroy
<christophe.leroy@xxxxxxxxxx> wrote:
>
>
>
> Le 14/06/2023 à 18:04, Nick Desaulniers a écrit :
> > On Wed, Jun 14, 2023 at 10:11 AM Christophe Leroy
> > <christophe.leroy@xxxxxxxxxx> wrote:
> >>
> >> Hi,
> >>
> >> Le 22/05/2023 à 21:00, kernel test robot a écrit :
> >>> Hi Christophe,
> >>>
> >>> FYI, the error/warning still remains.
> >>>
> >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>> head: 44c026a73be8038f03dbdeef028b642880cf1511
> >>> commit: 7245fc5bb7a966852d5bd7779d1f5855530b461a powerpc/math-emu: Remove -w build flag and fix warnings
> >>> date: 9 months ago
> >>> config: powerpc-randconfig-r022-20230522 (https://download.01.org/0day-ci/archive/20230523/202305230231.3Wb7Q68G-lkp@xxxxxxxxx/config)
> >>> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project b0fb98227c90adf2536c9ad644a74d5e92961111)
> >>> reproduce (this is a W=1 build):
> >>> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >>> chmod +x ~/bin/make.cross
> >>> # install powerpc cross compiling tool for clang build
> >>> # apt-get install binutils-powerpc-linux-gnu
> >>> # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7245fc5bb7a966852d5bd7779d1f5855530b461a
> >>> git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >>> git fetch --no-tags linus master
> >>> git checkout 7245fc5bb7a966852d5bd7779d1f5855530b461a
> >>> # save the config file
> >>> mkdir build_dir && cp config build_dir/.config
> >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=powerpc olddefconfig
> >>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=powerpc SHELL=/bin/bash arch/powerpc/math-emu/
> >>>
> >>> If you fix the issue, kindly add following tag where applicable
> >>> | Reported-by: kernel test robot <lkp@xxxxxxxxx>
> >>> | Closes: https://lore.kernel.org/oe-kbuild-all/202305230231.3Wb7Q68G-lkp@xxxxxxxxx/
> >>>
> >>> All warnings (new ones prefixed by >>):
> >>>
> >>>>> arch/powerpc/math-emu/fcmpu.c:13:2: warning: variable 'A_c' set but not used [-Wunused-but-set-variable]
> >>
> >> This code is imported, and there is no plan to make any change to it.
> >> Can you desactivate that warning ?
> >
> > If the code is imported, and we don't plan to push fixes upstream,
> > does it make sense to just set -Wno-unusued-but-set-variable in
> > arch/powerpc/math-emu/Makefile?
>
> Yes, that's done already but clang ignores it apparently.
>
> >
> > Wait, what?!
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/math-emu/Makefile#n20
> > arch/powerpc/math-emu/Makefile already has -Wunused-but-set-variable
> > in ccflags-remove-y. But if KBUILD_EXTRA_WARN is set for W=1 builds,
> > -Wunused-but-set-variable is added back, but only for math.o and
> > math_efp.o. The warning above comes from building fcmpu.o. So how
> > did -Wunused-but-set-variable get set in the first place?
>
> Indeed.
>
> I looked once more and found out that:
>
> clang -Wp,-MMD,arch/powerpc/math-emu/.fcmpu.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
> -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -Wundef -DKBUILD_EXTRA_WARN1
> -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
> --target=powerpc64le-linux-gnu -fintegrated-as
> -Werror=unknown-warning-option -Werror=ignored-optimization-argument
> -Werror=option-ignored -Werror=unused-command-line-argument -mbig-endian
> -m32 -msoft-float -pipe -mcpu=powerpc -mno-prefixed -mno-pcrel
> -mno-altivec -mno-vsx -mno-mma -mno-spe -fno-asynchronous-unwind-tables
> -mbig-endian -fno-delete-null-pointer-checks -Wno-frame-address
> -Wno-address-of-packed-member -O2 -Wframe-larger-than=1024
> -fno-stack-protector -Wno-gnu -Wno-unused-but-set-variable
> -Wno-unused-const-variable -ftrivial-auto-var-init=zero
> -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
> -pg -Wdeclaration-after-statement -Wvla -Wno-pointer-sign
> -Wcast-function-type -Wimplicit-fallthrough -fno-strict-overflow
> -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types
> -Wextra -Wunused -Wno-unused-parameter -Wmissing-format-attribute
> -Wold-style-definition -Wmissing-include-dirs -Wunused-const-variable
> -Wno-missing-field-initializers -Wno-sign-compare -Wno-type-limits
> -Wno-shift-negative-value -g -Werror
> -DKBUILD_MODFILE='"arch/powerpc/math-emu/fcmpu"'
> -DKBUILD_BASENAME='"fcmpu"' -DKBUILD_MODNAME='"fcmpu"'
> -D__KBUILD_MODNAME=kmod_fcmpu -c -o arch/powerpc/math-emu/fcmpu.o
> arch/powerpc/math-emu/fcmpu.c ; ./tools/objtool/objtool --mcount
> --uaccess --sec-address arch/powerpc/math-emu/fcmpu.o
>
>
> If you move -Wunused before -Wno-unused-but-set-variable, then you don't
> have the warning/error anymore. So what ? What the hell is clang
> behaving that way ?

It's re-enabling ALL of the members of the -Wunused group without
having checked to see if any more specific members were already
disabled.

>
> GCC documentation is explicit, see
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html :
>
> The combined effect of positive and negative forms is that more
> specific options have priority over less specific ones, independently of
> their position in the command-line.

Ah, nice citation. I did not know that was the expected behavior of
this group diagnostics. Indeed, there's a behavior difference here.
https://godbolt.org/z/13MxqrjcW

>
> Can clang be fixed ?

Filed:
https://github.com/llvm/llvm-project/issues/63315

>
> Christophe



--
Thanks,
~Nick Desaulniers