[PATCH] clocksource/arm_arch_timer: Fix bogus -Wsometimes-uninitialized warning

0 views
Skip to first unread message

Oliver Upton

unread,
Nov 7, 2021, 4:02:30 AM11/7/21
to linux-ar...@lists.infradead.org, Mark Rutland, Marc Zyngier, Daniel Lezcano, Nathan Chancellor, Nick Desaulniers, clang-bu...@googlegroups.com, Oliver Upton, kernel test robot
Since commit 4775bc63f880 ("clocksource/arm_arch_timer: Add build-time
guards for unhandled register accesses"), clang builds emit the
following warning:

>> drivers/clocksource/arm_arch_timer.c:156:3: warning: variable 'val' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~~~~~
drivers/clocksource/arm_arch_timer.c:163:9: note: uninitialized use occurs here
return val;
^~~

which is of course meaningless, as we break the build if the default
case is ever taken in the switch statement. Clang does static analysis
before deciding if the branch is ever taken, leading to the warning.

Fix the bogus warning by initializing val on the default branch.

Reported-by: kernel test robot <l...@intel.com>
Fixes: 4775bc63f880 ("clocksource/arm_arch_timer: Add build-time guards for unhandled register accesses")
Signed-off-by: Oliver Upton <oup...@google.com>
---
Heh, I had caught this earlier but didn't hit send before starting the
weekend. Saw the bot email, so sending out.

drivers/clocksource/arm_arch_timer.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 9a04eacc4412..8e2814fcea11 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -172,6 +172,7 @@ u32 arch_timer_reg_read(int access, enum arch_timer_reg reg,
val = readl_relaxed(timer->base + CNTP_CTL);
break;
default:
+ val = 0;
BUILD_BUG();
}
} else if (access == ARCH_TIMER_MEM_VIRT_ACCESS) {
@@ -181,6 +182,7 @@ u32 arch_timer_reg_read(int access, enum arch_timer_reg reg,
val = readl_relaxed(timer->base + CNTV_CTL);
break;
default:
+ val = 0;
BUILD_BUG();
}
} else {
--
2.34.0.rc0.344.g81b53c2807-goog

Oliver Upton

unread,
Nov 7, 2021, 4:11:14 AM11/7/21
to linux-ar...@lists.infradead.org, Mark Rutland, Marc Zyngier, Daniel Lezcano, Nathan Chancellor, Nick Desaulniers, clang-bu...@googlegroups.com, kernel test robot
On Sun, Nov 7, 2021 at 1:02 AM Oliver Upton <oup...@google.com> wrote:
>
> Since commit 4775bc63f880 ("clocksource/arm_arch_timer: Add build-time
> guards for unhandled register accesses"), clang builds emit the
> following warning:
>
> >> drivers/clocksource/arm_arch_timer.c:156:3: warning: variable 'val' is used uninitialized whenever switch default is taken [-Wsometimes-uninitialized]
> default:
> ^~~~~~~
> drivers/clocksource/arm_arch_timer.c:163:9: note: uninitialized use occurs here
> return val;
> ^~~
>
> which is of course meaningless, as we break the build if the default
> case is ever taken in the switch statement. Clang does static analysis
> before deciding if the branch is ever taken, leading to the warning.
>
> Fix the bogus warning by initializing val on the default branch.
>
> Reported-by: kernel test robot <l...@intel.com>
> Fixes: 4775bc63f880 ("clocksource/arm_arch_timer: Add build-time guards for unhandled register accesses")
> Signed-off-by: Oliver Upton <oup...@google.com>

My inbox searching was poor, there is another thread on this issue
where Miguel proposed tweaking the assertion such that clang no longer
emits the warning. No longer having issues with the patch applied [1]

[1] http://lore.kernel.org/r/2021101413...@kernel.org/

--
Oliver

Miguel Ojeda

unread,
Nov 8, 2021, 6:10:53 AM11/8/21
to Oliver Upton, Linux ARM, Mark Rutland, Marc Zyngier, Daniel Lezcano, Nathan Chancellor, Nick Desaulniers, clang-built-linux, kernel test robot
On Sun, Nov 7, 2021 at 10:11 AM 'Oliver Upton' via Clang Built Linux
<clang-bu...@googlegroups.com> wrote:
>
> My inbox searching was poor, there is another thread on this issue
> where Miguel proposed tweaking the assertion such that clang no longer
> emits the warning. No longer having issues with the patch applied [1]

Glad it helped! The fix is in mainline now.

Cheers,
Miguel
Reply all
Reply to author
Forward
0 new messages