Hi,
> On Jul 8, 2025, at 01:18, Jakub Jelinek <ja...@redhat.com> wrote:
>>
>>> 5th argument ACCESS_MODE:
>>> -1: Unknown access semantics
>>> 0: none
>>> 1: read_only
>>> 2: write_only
>>> 3: read_write
>>> 6th argument: A constant 0 with the pointer TYPE to the original flexible
>>> array type.
>>
>> Likewise, wouldn't this always be TREE_TYPE(TREE_TYPE(REF_TO_OBJ))? For a
>> FAM, the frontend does array_to_pointer, so with the INDIRECT_REF at the end
>> of build_access_with_size_for_counted_by gone, I reckon you should be able
>> to get the type of the array element. Likewise if it was a pointer and not
>> a FAM.
>>
>> TYPE_SIZE_UNIT may not work for them like you said, but there ought to be a
>> usable expression that we can reach from the type, no?
>
> No. The IL must clearly use the value (the size of the element), otherwise
> DCE or other passes will happily optimize it away, they don't keep some
> expression computation around just because it is referenced in
> TYPE_SIZE_UNIT of some type somewhere.
>
> Consider e.g.
> void bar (int *);
>
> void
> foo (int n, int m)
> {
> typedef int A[m];
> struct S { int n, m; A a[2]; A b[] __attribute__((counted_by (n))); } *p;
> p = __builtin_malloc (sizeof (struct S) + sizeof (A) * n);
> p->n = n;
> p->m = m;
> int *q = &p->b[1][0];
> bar (q);
> q = &p->b[0][1];
> bar (q);
> }
> There is a reason why e.g. COMPONENT_REF has 3 arguments rather than 2,
> the last one used solely for the variable length structures (primarily Ada,
> or GNU C extension like above).
Just filed PR121000: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
__builtin_dynamic_object_size should work for FAM with VLA element when
annotated with counted_by
Looks like that the current implementation of counted_by for FAM has a bug here
to handle this case.
Will study a little bit along with your comments in the other emails. And then
respond in another email.
Thanks a lot for the comments and testing case.
> Jakub
