Fix compiler warning about potentially uninitialized orig_fpmr variable:
testcases/fpmr_siginfo.c: In function ‘fpmr_present’: testcases/fpmr_siginfo.c:68:25: warning: ‘orig_fpmr’ may be used uninitialized in this function [-Wmaybe-uninitialized] fprintf(stderr, "FPMR in frame is %llx, was %llx\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fpmr_ctx->fpmr, orig_fpmr); ~~~~~~~~~~~~~~~~~~~~~~~~~~
Initialize orig_fpmr to 0 to resolve the warning.
Signed-off-by: Breno Leitao leitao@debian.org --- tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c b/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c index e9d24685e74194fc4ed1aebdcfd4c6edd3488e1b..26818860b223d367955d96e12d423fadc304700b 100644 --- a/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c +++ b/tools/testing/selftests/arm64/signal/testcases/fpmr_siginfo.c @@ -40,10 +40,10 @@ int fpmr_present(struct tdescr *td, siginfo_t *si, ucontext_t *uc) { struct _aarch64_ctx *head = GET_BUF_RESV_HEAD(context); struct fpmr_context *fpmr_ctx; + __u64 orig_fpmr = 0; size_t offset; bool in_sigframe; bool have_fpmr; - __u64 orig_fpmr;
have_fpmr = getauxval(AT_HWCAP2) & HWCAP2_FPMR; if (have_fpmr)
--- base-commit: 0d5248724ed8bc68c867c4c65dda625277f68fbc change-id: 20250207-arm_fix_selftest-ee29dbc33a06
Best regards,
On Fri, Feb 07, 2025 at 03:06:42AM -0800, Breno Leitao wrote:
Fix compiler warning about potentially uninitialized orig_fpmr variable:
testcases/fpmr_siginfo.c: In function ‘fpmr_present’: testcases/fpmr_siginfo.c:68:25: warning: ‘orig_fpmr’ may be used uninitialized in this function [-Wmaybe-uninitialized] fprintf(stderr, "FPMR in frame is %llx, was %llx\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fpmr_ctx->fpmr, orig_fpmr); ~~~~~~~~~~~~~~~~~~~~~~~~~~
This seems like something that should be reported to the compiler people, we only print the FPMR value if have_fpmr and there's an assignment to orig_fpmr in that case. Which compiler is this?
Hello Mark,
On Fri, Feb 07, 2025 at 05:26:06PM +0000, Mark Brown wrote:
On Fri, Feb 07, 2025 at 03:06:42AM -0800, Breno Leitao wrote:
Fix compiler warning about potentially uninitialized orig_fpmr variable:
testcases/fpmr_siginfo.c: In function ‘fpmr_present’: testcases/fpmr_siginfo.c:68:25: warning: ‘orig_fpmr’ may be used uninitialized in this function [-Wmaybe-uninitialized] fprintf(stderr, "FPMR in frame is %llx, was %llx\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fpmr_ctx->fpmr, orig_fpmr); ~~~~~~~~~~~~~~~~~~~~~~~~~~
This seems like something that should be reported to the compiler people, we only print the FPMR value if have_fpmr and there's an assignment to orig_fpmr in that case. Which compiler is this?
Good point. I am using: # gcc --version gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-2)
Clang, on the other hand, isn't upset about it.
# clang --target=aarch64-redhat-linux-gnu -fintegrated-as -Wall -O2 -g -I/home/leit/Devel/upstream/tools/testing/selftests/ -isystem /home/leit/Devel/upstream/usr/include -I/home/leit/Devel/upstream/tools/include -std=gnu99 -I. -Wno-address-of-packed-member -Wno-gnu-variable-sized-type-not-at-end -D_GNU_SOURCE= testcases/fpmr_siginfo.c test_signals.c test_signals_utils.c testcases/testcases.c signals.S sve_helpers.c -o testcases/fpmr_siginfo # clang --version clang version 19.1.3 (CentOS 19.1.3-1.el9)
On Fri, Feb 07, 2025 at 10:45:39AM -0800, Breno Leitao wrote:
On Fri, Feb 07, 2025 at 05:26:06PM +0000, Mark Brown wrote:
On Fri, Feb 07, 2025 at 03:06:42AM -0800, Breno Leitao wrote:
Fix compiler warning about potentially uninitialized orig_fpmr variable:
testcases/fpmr_siginfo.c: In function ‘fpmr_present’: testcases/fpmr_siginfo.c:68:25: warning: ‘orig_fpmr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
This seems like something that should be reported to the compiler people, we only print the FPMR value if have_fpmr and there's an assignment to orig_fpmr in that case. Which compiler is this?
Good point. I am using: # gcc --version gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-2)
Clang, on the other hand, isn't upset about it.
Right, and I'm not seeing it here either. I'm not opposed to applying the patch if enough people are using toolchains that have the issue, but these sorts of sledgehammer assignments aren't ideal since they mask issues.
linux-kselftest-mirror@lists.linaro.org
-
Breno Leitao -
Mark Brown