On 2025-07-07 08:48, Jakub Jelinek wrote:
The return value of .ACCESS_WITH_SIZE clobbering PTR (that subsequently gets
passed to __builtin_dynamic_object_size) should be sufficient to fully
prevent the reordering, it shouldn't have to clobber &PTR, I think.
The original use of .ACCESS_WITH_SIZE was designed for FAMs, for those
it IMHO does the right thing, it is a pass through first arg function
which attaches size information to the passed as well as returned pointer.
That pointer is &FAM, so address of the containing structure plus offsetof
of the FAM first element.
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 way it is used for non-FAMs looks just wrong.
It passes as first argument the address of the pointer, not the pointer
itself. So we have ifn used for two completely different purposes with
different meanings, while the arguments are otherwise pretty much the same
(or how do you uniquely distinguish the cases where it provides object
size for what it returns vs. where it provides object size for what the
pointer it returns points to). That is like the spaghetti code in certain
middle end warnings. For warnings it is really bad, for code generation
decisions it is a fatal design flaw.
So, either you need a different ifn, or add some flag in bitfield
that clearly distinguishes the 2 cases, or different number of arguments,
or perhaps most easily, why do the dereference at all?
If my argument to change .ACCESS_WITH_SIZE to refer to &a->fam[0] is not
convincing then it should probably be a distinct ifn,
.ACCESS_WITH_SIZE_PTR or something like that.
When I have
struct U { int n; int fam[n] __attribute__((counted_by (n))); } *u;
continue passing &u->fam as first argument and &u->n as second, while for
struct S {
int n;
int (*p)[n] __attribute__((counted_by(n)));
} *f;
don't pass &f->p to the builtin but pass f->p. You are providing size
for f->p pointer, not for &f->p pointer, while for FAM it is for &u->fam
pointer. The second argument would be &f->n.
So, my recommendation would be to revert the counted_by GCC 16 series,
rework it and submit again. Unless you can fix it up in a day or two.
I agree, this needs more thought.
Thanks,
Sid
