On 8/21/26 03:06, Jakub Jelinek wrote:
On Fri, Aug 21, 2026 at 10:56:34AM +0200, Richard Biener wrote:
On Fri, Aug 21, 2026 at 8:30 AM Gustavo A. R. Silva
<[email protected]> wrote:
For a pointer to a subobject whose record/union type ends in a flexible-array
member (directly, or through its trailing nested struct), addr_object_size()
walked up to the enclosing object (v = TREE_OPERAND (v, 0)) instead of
measuring the referenced subobject. __builtin_object_size() and
__builtin_dynamic_object_size() type 1 therefore returned the whole-object
size, collapsing type 1 onto type 0 and losing the distinction between
&p->inner and p. FORTIFY_SOURCE relies on the type-1 distinction, so this
weakens its bounds checks.
Fix this by computing the size directly from the referenced record/union
instead of walking up, restoring the type-0/type-1 distinction that Clang
already implements.
Bootstraped and regtested on x86_64-linux-gnu.
PR tree-optimization/126975
gcc/ChangeLog:
* tree-object-size.cc (addr_object_size): For a reference to a
record or union type, compute the object size from the referenced
subobject instead of walking up to the enclosing object when the
type recursively includes a flexible array member.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-pr101832.c (main): Update the expected
results of __builtin_object_size (..., 1) queries on subobjects
whose type contains a flexible array member.
---
.../gcc.dg/builtin-object-size-pr101832.c | 6 +++---
gcc/tree-object-size.cc | 18 +++++-------------
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
index 60078e11634..d76286ae454 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
@@ -92,9 +92,9 @@ int main (int argc, char *argv[])
outer = (void *)magic1;
outest = (void *)magic2;
- expect (__builtin_object_size (&outer->a, 1), -1);
- expect (__builtin_object_size (&outest->b, 1), -1);
- expect (__builtin_object_size (&outest->b.a, 1), -1);
+ expect (__builtin_object_size (&outer->a, 1), sizeof(outer->a));
I think this warrants updating the documentation in extend.texi where
I think the
question is how for
struct A {
int n;
char data[];
};
struct B {
int m;
struct A a;
};
structr B *outer;
and object &outer->a, how, based on 'type', the enclosing object
size is constrained by its enclosing object. Also for outer->a.data
what the enclosing object is and similar how the constraint from the
enclosing objects are handled.
I'll note that __builtin_object_size behavior might be in conflict
with constraints set by -fstrict-flex-arrays. IIRC "nested" flex arrays
are a GNU extension, flex arrays not at the end of an (enclusing)
object as well (a particularly bad one).
You also need to update the toplevel comment of the testcase
which explicitly says your change is wrong.
I actually think we don't want to change this, the handling of nested
flexible and flexible-like arrays has been completely intentional, it was
based on investigation of real-world code and finding some reasonable
middle-ground on what we consider already invalid and what we allow as an
extension, especially because it occurs a lot in real-world code.
The current behavior was introduced in GCC 14 (mid-2023). Before that,
the code behaved as expected today.
Before GCC 14:
ok: __builtin_object_size (&p->inner, 1) == 8
ok: __builtin_dynamic_object_size (&p->inner, 1) == 8
ok: __builtin_object_size (&p->inner, 0) == 56
ok: __builtin_dynamic_object_size (&p->inner, 0) == 56
GCC 14.1+:
WAT: __builtin_object_size (&p->inner, 1) == 56 (expected 8)
WAT: __builtin_dynamic_object_size (&p->inner, 1) == 56 (expected 8)
ok: __builtin_object_size (&p->inner, 0) == 56
ok: __builtin_dynamic_object_size (&p->inner, 0) == 56
See: https://godbolt.org/z/Td8sW7G47
What we certainly can change is the behavior when
-fstrict-flex-arrays unless it already behaves the expected way,
and perhaps also when the flex array has counted_by attribute.
Changing this unconditionally will just break a lot of software in the wild
when compiled with -O2 -D_FORTIFY_SOURCE=2 or -O2 -D_FORTIFY_SOURCE=3, which
is very common.
I'm fine with implementing this under -fstrict-flex-arrays=3, which is the
strictest level value for flexible-array members we use in the Linux kernel.
However, given that just three years ago (before GCC 14, as shown above) GCC
already had the behavior this change restores, I think this should probably be
an unconditional change. What do you think?
Also, notice how the behavior for one-element and zero-length arrays, which
we call "fake flexible arrays" in the Linux kernel, is exactly the same
before GCC 14 and now:
Before GCC 14:
[ ] C99 flexible-array member
ok: __builtin_object_size (&p->inner, 1) == 8
ok: __builtin_dynamic_object_size (&p->inner, 1) == 8
ok: __builtin_object_size (&p->inner, 0) == 56
ok: __builtin_dynamic_object_size (&p->inner, 0) == 56
[1] fake flexible-array member
ok: __builtin_object_size (&p_1->inner_1, 1) == 16
ok: __builtin_dynamic_object_size (&p_1->inner_1, 1) == 16
ok: __builtin_object_size (&p_1->inner_1, 0) == 64
ok: __builtin_dynamic_object_size (&p_1->inner_1, 0) == 64
[0] fake flexible-array member
ok: __builtin_object_size (&p_0->inner_0, 1) == 8
ok: __builtin_dynamic_object_size (&p_0->inner_0, 1) == 8
ok: __builtin_object_size (&p_0->inner_0, 0) == 56
ok: __builtin_dynamic_object_size (&p_0->inner_0, 0) == 56
GCC 14.1+:
[ ] C99 flexible-array member
WAT: __builtin_object_size (&p->inner, 1) == 56 (expected 8)
WAT: __builtin_dynamic_object_size (&p->inner, 1) == 56 (expected 8)
ok: __builtin_object_size (&p->inner, 0) == 56
ok: __builtin_dynamic_object_size (&p->inner, 0) == 56
[1] fake flexible-array member
ok: __builtin_object_size (&p_1->inner_1, 1) == 16
ok: __builtin_dynamic_object_size (&p_1->inner_1, 1) == 16
ok: __builtin_object_size (&p_1->inner_1, 0) == 64
ok: __builtin_dynamic_object_size (&p_1->inner_1, 0) == 64
[0] fake flexible-array member
ok: __builtin_object_size (&p_0->inner_0, 1) == 8
ok: __builtin_dynamic_object_size (&p_0->inner_0, 1) == 8
ok: __builtin_object_size (&p_0->inner_0, 0) == 56
ok: __builtin_dynamic_object_size (&p_0->inner_0, 0) == 56
See: https://godbolt.org/z/8Pn361TM8
So, this change doesn't affect how those arrays are interpreted by
__bos/__bdos() when used as fake flexible arrays today (that is,
without -fstrict-flex-arrays).
Thanks for the feedback!
-Gustavo
