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.
Thanks,
Sid
