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.
This patch seems to DTRT, though. It doesn't appear to regress merging
in a meaningful way for the Linux at least.
> 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
--
Kees Cook
