From: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
To: Amit Machhiwal <amachhiw@linux.ibm.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Cc: Vaibhav Jain <vaibhav@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>, Greg Kurz <groug@kaod.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/powerpc: Suppress false positive -Wmaybe-uninitialized with GCC 15
Date: Tue, 10 Mar 2026 11:54:31 +0100 [thread overview]
Message-ID: <3f26916b-5a1f-40b0-9c47-8b53e066e08c@kernel.org> (raw)
In-Reply-To: <20260310101519.67157-1-amachhiw@linux.ibm.com>
Le 10/03/2026 à 11:15, Amit Machhiwal a écrit :
> 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(), this error
> is not seen during compilation because GCC 15 seems to consider 'retbuf'
> always populated from the hypervisor which is eventually referred by
> 'be_packed'. However, GCC 15's dataflow analysis can’t prove the same
> before the first dereference when vphn_unpack_associativity() is called
> from test_one() with pre-initialized array of 'struct test'. 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.
>
> Suppress the warning locally around the offending statement when
> building with GCC 15 using a diagnostic pragma. This keeps the build
> working while limiting the scope of the suppression to the specific
> statement that triggers the false positive. An issue [1] has also been
> created on GCC bugzilla.
Usually when we get this kind of warning this is because the code is too
complex. We should try to make it more obvious instead of just hiding
the warning.
Here the for loop is a bit misleading.
>
> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D124427&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C06a4d55b55f24c5cf00208de7e8e3676%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639087346428583316%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xEfO94N6IfGYhmmapNFduv3OrMarxpjTpZR6B38uR1s%3D&reserved=0
>
> 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>
> ---
> arch/powerpc/platforms/pseries/vphn.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/vphn.c b/arch/powerpc/platforms/pseries/vphn.c
> index 3f85ece3c872..9bc891143fec 100644
> --- a/arch/powerpc/platforms/pseries/vphn.c
> +++ b/arch/powerpc/platforms/pseries/vphn.c
> @@ -39,7 +39,22 @@ static int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
> be_packed[i] = cpu_to_be64(packed[i]);
>
> for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
> +/*
> + * When this function is called from hcall_vphn(), GCC 15 seems to consider
> + * 'retbuf' always populated from the hypervisor which is eventually referred by
> + * 'be_packed'. However, GCC 15's dataflow analysis can’t prove the same before
> + * the first dereference when this function is called from test_one() with
> + * pre-initialized array of 'struct test'. This results in a false positive
> + * '-Wmaybe-uninitialized' warning which is promoted to an error under
> + * '-Werror'. This problem is not seen when the compilation is performed with
> + * older GCC versions.
> + */
> +#pragma GCC diagnostic push
> +#if defined(__GNUC__) && __GNUC__ >= 15
> +#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> +#endif
> u16 new = be16_to_cpup(field++);
> +#pragma GCC diagnostic pop
>
> if (is_32bit) {
> /*
>
> base-commit: 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681
next prev parent reply other threads:[~2026-03-10 10:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 10:15 [PATCH] selftests/powerpc: Suppress false positive -Wmaybe-uninitialized with GCC 15 Amit Machhiwal
2026-03-10 10:54 ` Christophe Leroy (CS GROUP) [this message]
2026-03-12 13:16 ` Amit Machhiwal
2026-03-12 18:56 ` David Laight
2026-03-16 6:01 ` Amit Machhiwal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f26916b-5a1f-40b0-9c47-8b53e066e08c@kernel.org \
--to=chleroy@kernel.org \
--cc=amachhiw@linux.ibm.com \
--cc=groug@kaod.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=vaibhav@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox