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

[Kees Cook <kees@kernel.org>]

On Wed, Nov 19, 2025 at 11:49:23PM -0700, Nathan Chancellor wrote:
> On Wed, Nov 19, 2025 at 02:44:31PM -0800, Kees Cook wrote:
> > Enable GCC 16's coming "-fdiagnostics-show-context=2" 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.
> > 
> > The context depth of 2 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.
> 
> Would we ever want a depth more than 2? In other words, should this be
> customizable in case there is a warning that needs more context?

Honestly, I'm not sure yet. I think if we find it to be true, we can
add it then. So far, everything I've found works with =1, but I went
with =2 just to be conservative. (And I did build time comparisons --
there is no measurable difference between off, 1, or 2.)

> > 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.
> 
> Not that it is that different from what you describe here but having an
> actual example of the insight that this gives using a problematic case
> from the past (such as one that resulted in these various warnings
> getting disabled) might be useful for future travellers.

Yeah, I can list some of the prior fixes.

> > Link: https://github.com/gcc-mirror/gcc/commit/6faa3cfe60ff9769d1bebfffdd2c7325217d7389 [1]
> 
> I have a small preference for using links that the project controls,
> i.e.
> 
>   https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6faa3cfe60ff9769d1bebfffdd2c7325217d7389
> 
> but I am guessing that mirror is not going anywhere and we have the hash
> regardless so consider it a nit.

I regularly have gcc.gnu.org time out for me, so I've been using github
for trees and references, but I can change this.

> 
> > Signed-off-by: Kees Cook <kees@kernel.org>
> > ---
> 
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>

Thanks!

> Should we take this via Kbuild or do you want to take it via the
> hardening tree?

I figured I'd take it via the hardening tree, but I have no strong
rationale for that. ;)

-Kees

-- 
Kees Cook