Re: [PATCH v2] kbuild: Enable GCC diagnostic context for value-tracking warnings

[Nicolas Schier <nsc@kernel.org>]

On Fri, Nov 21, 2025 at 10:43:48AM -0800, Kees Cook wrote:
> Enable GCC 16's coming "-fdiagnostics-show-context=N" option[1] to
> provide enhanced diagnostic information for value-tracking warnings,
> which displays the control flow chain leading to the diagnostic. This
> covers our existing use of -Wrestrict and -Wstringop-overread, and
> gets us closer to enabling -Warray-bounds, -Wstringop-overflow, and
> -Wstringop-truncation, so we can track the rationale for the warning,
> letting us more quickly identify actual issues vs what have looked in
> the past like false positives. Fixes based on this work have already
> been landing, e.g.:
> 
>   4a6f18f28627 ("net/mlx4_core: Avoid impossible mlx4_db_alloc() order value")
>   8a39f1c870e9 ("ovl: Check for NULL d_inode() in ovl_dentry_upper()")
>   e5f7e4e0a445 ("drm/amdgpu/atom: Work around vbios NULL offset false positive")
> 
> The context depth ("=N") provides the immediate decision path that led
> to the problematic code location, showing conditional checks and branch
> decisions that caused the warning. This will help us understand why
> GCC's value-tracking analysis triggered the warning and makes it easier
> to determine whether warnings are legitimate issues or false positives.
> 
> For example, an array bounds warning will now show the conditional
> statements (like "if (i >= 4)") that established the out-of-bounds access
> range, directly connecting the control flow to the warning location.
> This is particularly valuable when GCC's interprocedural analysis can
> generate warnings that are difficult to understand without seeing the
> inferred control flow.
> 
> While my testing has shown that "=1" reports enough for finding
> the origin of most bounds issues, I have used "=2" here just to be
> conservative. Build time measurements with this option off, =1, and =2
> are all with noise of each other, so there seems to be no harm in "turning
> it up". If we need to, we can make this value configurable in the future.
> 
> Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6faa3cfe60ff9769d1bebfffdd2c7325217d7389 [1]
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
> Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: Nicolas Schier <nicolas.schier@linux.dev>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Cc: <linux-kbuild@vger.kernel.org>
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index d14824792227..d97452441cd0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -940,6 +940,9 @@ KBUILD_CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
>  # for the randomize_kstack_offset feature. Disable it for all compilers.
>  KBUILD_CFLAGS	+= $(call cc-option, -fno-stack-clash-protection)
>  
> +# Get details on warnings generated due to GCC value tracking.
> +KBUILD_CFLAGS	+= $(call cc-option, -fdiagnostics-show-context=2)
> +
>  # Clear used registers at func exit (to reduce data lifetime and ROP gadgets).
>  ifdef CONFIG_ZERO_CALL_USED_REGS
>  KBUILD_CFLAGS	+= -fzero-call-used-regs=used-gpr
> -- 
> 2.34.1
> 

Thanks!

Reviewed-by: Nicolas Schier <nsc@kernel.org>