On Wed, Jul 23, 2025 at 05:59:22PM +0000, Qing Zhao wrote:
> struct S {
> int n;
> int *p __attribute__((counted_by(n)));
> } *f;
> Int *g;
> void setup (int **ptr, int count)
> {
> *ptr = __builtin_malloc (sizeof (int) * count);
> g = *ptr;
> };
> int main ()
> {
> f = __builtin_malloc (sizeof (struct S));
> setup (&f->p, 10);
This is neither read nor write, it is taking an address of f->p.
The above case is definitely questionable because nothing really initializes
f->n, so any later uses of f->p would be invalid unless it is initialized
first.
Anyway, the choices are not mark with .ACCESS_WITH_SIZE taking address of
such pointers, or mark it with another mode and handle it differently later.
At least for the start, I'd strongly suggest the former.
With the above setup mess, it will always be just best effort, if it is
inline, bos pass can see what it has been initialized to and associated
with, if not, then it will simply not know it has an counted_by attribute.
> C FE has no such capability to determine whether the f->p is a read or a
> write. Is this right?
C certainly can determine that, otherwise e.g. the -Wunused-but-set-*
warnings wouldn't work.
If there is an lvalue to rvalue conversion, it was read, so you can attach
.ACCESS_WITH_SIZE to that if it is COMPONENT_REF with pointer type with
counted_by attribute.
If there is not an lvalue to rvalue conversion, it is write or something
else.
So, one possibility is e.g. to look for mark_exp_read calls.
Another is try default_function_array_read_conversion and a few other spots.
Or another option might be don't mark even the loads with .ACCESS_WITH_SIZE
when pointer type, tweak the content of the counted_by attribute (its
argument) instead on the FIELD_DECLs such that the middle-end could figure
it out and just handle it on the bos pass side. Though if counted_by
argument is not just an identifier of a field in the same structure but
complex expression, trying to reintroduce it into the IL might be too
challenging at that point.
Jakub
