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.

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.

Link: https://github.com/gcc-mirror/gcc/commit/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

On Wed, Nov 19, 2025 at 11:44 PM Kees Cook <kees@kernel.org> 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.

I am probably missing some context, but in what sense gets us closer?
Do you mean it will make it easier to understand those when we enable
them? i.e. we still can't enable them until the minimum is upgraded,
right?

Apart from that, it looks like a nice improvement on the output from
the PR examples -- I didn't test it, but the patch itself looks fine
of course:

Reviewed-by: Miguel Ojeda <ojeda@kernel.org>

Thanks!

Cheers,
Miguel

On Thu, Nov 20, 2025 at 09:17:16AM +0100, Miguel Ojeda wrote:
> On Wed, Nov 19, 2025 at 11:44 PM Kees Cook <kees@kernel.org> 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.
> 
> I am probably missing some context, but in what sense gets us closer?
> Do you mean it will make it easier to understand those when we enable
> them? i.e. we still can't enable them until the minimum is upgraded,
> right?

Right -- we've been tracking down -Warray-bounds warnings for several
years now and it has been quite difficult to determine which are "real"
and which are false positives. This option makes the "real" cases much
more obvious.

I will improve the commit log.

> Apart from that, it looks like a nice improvement on the output from
> the PR examples -- I didn't test it, but the patch itself looks fine
> of course:
> 
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>

Thanks!

-- 
Kees Cook

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?

> 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.

> 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.

> Signed-off-by: Kees Cook <kees@kernel.org>
> ---

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

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

> ---
>  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
>

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