On 2025-07-07 09:14, Jakub Jelinek wrote:
So that ought to be &a->fam[0] right, and not &a->fam? It means the same
for a FAM, so why not specify it as &a->fam[0] (or simply a->fam)? That will
be consistent with when fam is a pointer.
The only difference between &a->fam[0] and &a->fam is not the value (that is
the same), just the type in one case say int *, in the other int [0:] *.
At least in GIMPLE pointer conversions are useless, so what exact type of
the argument is doesn't matter that much, but it matters e.g. when you're
dereferencing it.
Yes, that's why I'm thinking that we could use that flexibility match
the type passed to .ACCESS_WITH_SIZE with that in
__builtin_dynamic_object_size. There it's almost always a->fam or
&a->fam[0] in practice, rarely ever &a->fam.
Even in the rare case of __builtin_dynamic_object_size being passed
&a->fam, shouldn't a->fam = .ACCESS_WITH_SIZE(a->fam, ...) ought to be
sufficient in its minimal function of preventing reordering? There's no
actual dereference in .ACCESS_WITH_SIZE (it's a nop in practice, just a
reordering barrier until the __builtin_dynamic_object_size call is
replaced), so maybe we could do this?
Now, for
int n; int (*p)[n] __attribute__((counted_by(n)));
f->p has the int [n] * type, so guess that is what you want to use.
So to look at it another way the "leap of imagination" I'm suggesting is
to see int p[] as, essentially int (*p)[], which then ends up matching
both cases that .ACCESS_WITH_SIZE could potentially support.
Sid
