On Wed, 14 Oct 2026, Kees Cook wrote:
> On Sun, Oct 11, 2026 at 04:50:41PM +0200, Richard Biener wrote:
> > > In function 'small_to_big', inlined from 'f' at t.c:22:3:
> > > warning: array subscript 'struct big[0]' is partly outside array
> > > bounds of 'struct small[1]' [-Warray-bounds=]
> >
> > I think these diagnostics are dubious with -fno-strict-aliasing which
> > essentially says you can access every object via any other objects type.
>
> The source has no such access, though: each function reads and writes
> members through its own types, and every byte touched is inside the
> object. The "struct big" access to a "struct small" exists only in the
> body ICF picked, so the warning is about code GCC wrote rather than
> code the programmer wrote.
>
> > So instead of this I'd rather work towards inlining the original
> > body rather than the ICF prevailing one.
>
> That does seem like it could be better, but it's not clear to me how
> large a project that would be to accomplish.
I think for the case of ICF and non-LTO it should be possible to
"hack" this in; it should be just to make sure the inline edges
point to the original body and hopefully the ICF "merge" is somehow
encoded clearly. When the inline edge is set up correctly it should
possibly even work with LTO.
> This patch seems to DTRT, though. It doesn't appear to regress merging
> in a meaningful way for the Linux at least.
I don't dispute this, but it feels like a hack. Either ICF should
work as if -fstrict-aliasing were given, but consistently so, and
for a good reason, or you could as well do -fno-ipa-icf when
building the kernel as you are doing so many we-don't-quite-want-C
things already.
> > And force-disable these kind of diagnostics with -fno-strict-aliasing?
>
> I'd really rather not. Linux builds everything with -fno-strict-aliasing,
> so that would remove these checks from the kernel entirely. GCC's
> -Warray-bounds is still off by default for the kernel because of false
> positives like this one (which is why I'm trying to solve it), and I've
> been working toward enabling it, since it finds real bugs. (I have a
> stack of a dozen real issues that this found while doing a recent pass.)
>
> For example (since I don't yet have links to the above stack), here
> are some random examples from a few years ago: a response struct passed
> where a bigger error struct was expected, whose "error" field was past
> the end of the object[1]:
>
> drivers/thunderbolt/xdomain.c:226:22: error: array subscript 'const struct
> tb_xdp_error_response[0]' is partly outside array bounds of 'struct
> tb_xdp_properties_changed_response[1]'
>
> and a u64 remainder stored into an int on the stack[2]:
>
> include/linux/math64.h:56:20: error: array subscript 'u64 {aka long long
> unsigned int}[0]' is partly outside array bounds of 'int[1]'
>
> But if you did disable diagnostics, which did you have in mind? If it's
> only warnings about an access whose type is bigger than the object while
> the bytes it touches are in bounds, that's narrower, but the first
> example above would still need to be caught, so I'd much rather just
> get ICF behaving nicely. :)
>
> -Kees
>
> [1] https://git.kernel.org/linus/19813551701d0
> [2] https://git.kernel.org/linus/9f3d543a9f737
>
>
--
Richard Biener <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Stefan Gaiser, Jochen Jaser, Abhinav Puri; (HRB 36809, AG Nuernberg)
