Hi,
Sorry for the late reply. And thanks a lot for all the help so far.
For the documantion of the .ACCESS_WITH_SIZE for pointers, please see the
following in c/c-typeck.cc <http://c-typeck.cc/>:
/* Given a COMPONENT_REF REF with the location LOC, the corresponding
COUNTED_BY_REF, and the COUNTED_BY_TYPE, generate the corresponding
call to the internal function .ACCESS_WITH_SIZE.
Generate an INDIRECT_REF to a call to the internal function
.ACCESS_WITH_SIZE.
REF
to:
(*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1,
(TYPE_OF_ARRAY *)0))
NOTE: The return type of this function is the POINTER type pointing
to the original flexible array type or the original pointer type.
Then the type of the INDIRECT_REF is the original flexible array type
or the original pointer type.
The 4th argument of the call is a constant 0 with the TYPE of the
object pointed by COUNTED_BY_REF.
The 6th argument of the call is a constant 0 of the same TYPE as
the return type of the call.
*/
static tree
build_access_with_size_for_counted_by (location_t loc, tree ref,
tree counted_by_ref,
tree counted_by_type)
Qing
> On Jul 7, 2025, at 02:05, Richard Biener <richard.guent...@gmail.com> wrote:
>
> On Sat, Jul 5, 2025 at 2:10 PM Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>>
>> On 2025-07-05 07:23, Richard Biener wrote:
>>>> OK, should I revert right away or can we wait till Qing returns on Monday?
>>>
>>> Monday is OK with me.
>>>
>>
>> Thanks, so I thought about this some more and I think when I said in
>> bugzilla:
>>
>> "In fact, maybe the .ACCESS_WITH_SIZE handling in objsz probably needs
>> improvement to express it better, but that's an orthogonal matter."
>>
>> I had the right intuition but I was completely wrong about it being an
>> orthogonal matter. That *is* the issue and it only becomes relevant
>> when the member being described is a pointer and not a FAM. e.g. for
>> the following:
>>
>> ```
>> struct A
>> {
>> int count;
>> #ifndef PTR
>> char c[] __attribute ((__counted_by__ (count)));
>> #else
>> char *c __attribute ((__counted_by__ (count)));
>> #endif
>> } a;
>>
>> unsigned long
>> foo (struct A *a)
>> {
>> return __builtin_dynamic_object_size (a->c, 1);
>> }
>> ```
>>
>> the .ACCESS_WITH_SIZE abstraction records the size using &a->c:
>>
>> _2 = &a->c;
>> _3 = &a->count;
>> _1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
>> D.2964 = __builtin_dynamic_object_size (_1, 1);
>>
>> this doesn't make a difference when c is an array since the & operator
>> is a nop. However when the same is applied to the pointer a->c, it
>> becomes an additional dereference, which changes the semantic meaning:
>>
>> _2 = &a->c;
>> _3 = &a->count;
>> _1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
>> _4 = *_1;
>> D.2964 = __builtin_dynamic_object_size (_4, 1);
>>
>> Since the intent of the .ACCESS_WITH_SIZE was to associate the storage
>> of count with c to prevent reordering, maybe the semantically correct
>> solution here is that when c is a pointer, the frontend emits:
>>
>> _2 = a->c;
>> _3 = &a->count;
>> _1 = .ACCESS_WITH_SIZE (_2, _3, 1, 0, -1, 0B);
>> D.2964 = __builtin_dynamic_object_size (_, 1);
>>
>> so a->c instead of &a->c.
>
> Yes. That's what I'd have expected happens? I thought .ACCESS_WITH_SIZE
> annotates the pointer, it doesn't perform an access itself - correct? Where
> is .ACCESS_WITH_SIZE documented? I can't find it documented in the
> internals manual, internal-fn.def has
>
> /* A function to associate the access size and access mode information
> with the corresponding reference to an object. It only reads from the
> 2nd argument. */
> DEF_INTERNAL_FN (ACCESS_WITH_SIZE, ECF_PURE | ECF_LEAF | ECF_NOTHROW, NULL)
>
> that suggests .ACCESS_WITH_SIZE performs a read on the size. It doesn't
> say what the function returns at all.
>
> Is the above only happening
> when using __builtin_dynamic_object_size (_1, 1) or also when performing
> an actual access like
>
> return a->c[i];
>
> ?
>
>> In fact, maybe taking the address of a->c
>> doesn't make sense in general and .ACCESS_WITH_SIZE should always be the
>> above even for FAM? Does that sound correct?
>>
>> Sid
