> On Jul 7, 2025, at 11:58, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>
> On 2025-07-07 09:33, Siddhesh Poyarekar wrote:
>>> 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?
>
> I apologize, I based my understanding of .ACCESS_WITH_SIZE based on my faulty
> memory from discussions last year and not on what actually got implemented.
> Upon looking closer, this looks wrong to me for pointer:
>
> tree first_param = is_fam ? array_to_pointer_conversion (loc, ref)
> : build_unary_op (loc, ADDR_EXPR, ref, false);
>
> /* The result type of the call is a pointer to the original type
> of the ref. */
> tree result_type = c_build_pointer_type (TREE_TYPE (ref));
>
> We shouldn't be building an ADDR_EXPR for pointers, that's not equivalent to
> what's happening for FAM. For the FAM case, the array_to_pointer conversion
> will make a cast (TYPE *)a->fam. So for analogous treatment for pointers, it
> should be passed on directly, no need to build the ADDR_EXPR.
>
> Also, I don't see why the result_type needs to be deduced separately instead
> of simply passing on TREE_TYPE (first_param), since
> array_to_pointer_conversion should set the type of the pointer to be the same
> as the element type.
As I mentioned in the latest email I replied to the thread, the original
implementation of the counted_by for pointer was implemented without the
additional indirection.
But that implementation has a fundamental bug during testing. then I changed
the implementation like the current.
I need spending a little more time to find the details of that fundamental bug
with the original implementation.
If the current bug is urgent to be fixed. and you are not comfortable with the
simple Patch Sid provided, then I am okay to back it out now and then push it
back with the fix to this current bug at a later time after everyone is
comfortable with the current implementation.
Thanks a lot!
Qing
>
> Thanks,
> Sid
