Re: [PATCH v2] selftests/powerpc: Suppress -Wmaybe-uninitialized with GCC 15

[Venkat <venkat88@linux.ibm.com>]

> On 13 Mar 2026, at 10:24 PM, Amit Machhiwal <amachhiw@linux.ibm.com> wrote:
> 
> GCC 15 reports the below false positive '-Wmaybe-uninitialized' warning
> in vphn_unpack_associativity() when building the powerpc selftests.
> 
>  # make -C tools/testing/selftests TARGETS="powerpc"
>  [...]
>    CC       test-vphn
>  In file included from test-vphn.c:3:
>  In function ‘vphn_unpack_associativity’,
>      inlined from ‘test_one’ at test-vphn.c:371:2,
>      inlined from ‘test_vphn’ at test-vphn.c:399:9:
>  test-vphn.c:10:33: error: ‘be_packed’ may be used uninitialized [-Werror=maybe-uninitialized]
>     10 | #define be16_to_cpup(x)         bswap_16(*x)
>        |                                 ^~~~~~~~
>  vphn.c:42:27: note: in expansion of macro ‘be16_to_cpup’
>     42 |                 u16 new = be16_to_cpup(field++);
>        |                           ^~~~~~~~~~~~
>  In file included from test-vphn.c:19:
>  vphn.c: In function ‘test_vphn’:
>  vphn.c:27:16: note: ‘be_packed’ declared here
>     27 |         __be64 be_packed[VPHN_REGISTER_COUNT];
>        |                ^~~~~~~~~
>  cc1: all warnings being treated as errors
> 
> When vphn_unpack_associativity() is called from hcall_vphn() in kernel
> the error is not seen while building vphn.c during kernel compilation.
> This is because the top level Makefile includes '-fno-strict-aliasing'
> flag always.
> 
> The issue here is that GCC 15 emits '-Wmaybe-uninitialized' due to type
> punning between __be64[] and __b16* when accessing the buffer via
> be16_to_cpup(). The underlying object is fully initialized but GCC 15
> fails to track the aliasing due to the strict aliasing violation here.
> Please refer [1] and [2]. This results in a false positive warning which
> is promoted to an error under '-Werror'. This problem is not seen when
> the compilation is performed with GCC 13 and 14. An issue [1] has also
> been created on GCC bugzilla.
> 
> The selftest compiles fine with '-fno-strict-aliasing'. Since this GCC
> flag is used to compile vphn.c in kernel too, the same flag should be
> used to build vphn tests when compiling vphn.c in the selftest as well.
> 
> Fix this by including '-fno-strict-aliasing' during vphn.c compilation
> in the selftest. This keeps the build working while limiting the scope
> of the suppression to building vphn tests.
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124427
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768
> 
> Fixes: 58dae82843f5 ("selftests/powerpc: Add test for VPHN")
> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---

Tested this patch, and it fixes reported issue.

Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>

WithOut This Patch:

make -j32
  CC       test-vphn
In file included from test-vphn.c:3:
In function ‘vphn_unpack_associativity’,
    inlined from ‘test_one’ at test-vphn.c:371:2,
    inlined from ‘test_vphn’ at test-vphn.c:399:9:
test-vphn.c:10:33: error: ‘be_packed’ may be used uninitialized [-Werror=maybe-uninitialized]
   10 | #define be16_to_cpup(x)         bswap_16(*x)
      |                                 ^~~~~~~~
vphn.c:42:27: note: in expansion of macro ‘be16_to_cpup’
   42 |                 u16 new = be16_to_cpup(field++);
      |                           ^~~~~~~~~~~~
In file included from test-vphn.c:19:
vphn.c: In function ‘test_vphn’:
vphn.c:27:16: note: ‘be_packed’ declared here
   27 |         __be64 be_packed[VPHN_REGISTER_COUNT];
      |                ^~~~~~~~~
cc1: all warnings being treated as errors
make: *** [../../lib.mk:225: /home/upstreamci/linux/tools/testing/selftests/powerpc/vphn/test-vphn] Error 1


With This Patch:

make run_tests 
TAP version 13
1..1
# timeout set to 130
# selftests: powerpc/vphn: test-vphn
# test: test-vphn
# tags: git_version:ec7d5e129
# success: vphn: no data
# success: vphn: 1 x 16-bit value
# success: vphn: 2 x 16-bit values
# success: vphn: 3 x 16-bit values
# success: vphn: 4 x 16-bit values
# success: vphn: 5 x 16-bit values
# success: vphn: 24 x 16-bit values
# success: vphn: 1 x 32-bit value
# success: vphn: 2 x 32-bit values
# success: vphn: 3 x 32-bit values
# success: vphn: 12 x 32-bit values
# success: vphn: 16-bit value followed by 32-bit value
# success: vphn: 32-bit value followed by 16-bit value
# success: vphn: 16-bit value followed by 2 x 32-bit values
# success: vphn: 32-bit value has all ones in 16 lower bits
# success: vphn: last 32-bit value is truncated
# success: vphn: garbage after terminator
# success: test-vphn
ok 1 selftests: powerpc/vphn: test-vphn


Regards,
Venkat.
> Changes since v2:
>  * Compile vphn test with '-fno-strict-aliasing' as per the indications in the
>    [1] instead of locally suppressing the '-Wmaybe-uninitialized' warning with
>    diagnostic pragma
>  * v1: https://lore.kernel.org/all/20260310101519.67157-1-amachhiw@linux.ibm.com/
> ---
> tools/testing/selftests/powerpc/vphn/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/powerpc/vphn/Makefile b/tools/testing/selftests/powerpc/vphn/Makefile
> index 61d519a076c6..778fc396340d 100644
> --- a/tools/testing/selftests/powerpc/vphn/Makefile
> +++ b/tools/testing/selftests/powerpc/vphn/Makefile
> @@ -5,7 +5,7 @@ top_srcdir = ../../../../..
> include ../../lib.mk
> include ../flags.mk
> 
> -CFLAGS += -m64 -I$(CURDIR)
> +CFLAGS += -m64 -I$(CURDIR) -fno-strict-aliasing
> 
> $(TEST_GEN_PROGS): ../harness.c
> 
> 
> base-commit: 0257f64bdac7fdca30fa3cae0df8b9ecbec7733a
> -- 
> 2.50.1 
>