On 12/16/25 03:27, Richard Biener wrote:
Is this just a "faulty" test situation now if we can identify that buf3
and buf1 points to the same thing?
Or am I missing something...?
IIRC the execute/builtins tests play tricks behind our backs, introducing
extra side-effects of the builtin calls. That harness should be re-architected.
But your problem at hand seems to be that you are confusing
the objsz pass and the test expects to optimize _chk to no-_chk
variants?
And next I get a problem in gcc.dg/builtin-object-size-4.c. This time,
its because we have:
struct A
{
char a[10];
int b;
char c[10];
} y, w[4];
<...>
_28 = &a.a[4] + 2;
I attempt to fold that into a new reference via
gimple_fold_stmt_to_constant_1, and instead of
&a.a[6]
I get
&MEM <char> [(void *)&a + 6B]
When we invoke __builtin_object_size() on the second expression, it uses
the entire object size of A and returns 20 instead of the 4 we are
looking for .
in gimple_fold_stmt_to_constant_1 it executes:
if (subcode == POINTER_PLUS_EXPR)
{
tree op0 = (*valueize) (gimple_assign_rhs1 (stmt));
tree op1 = (*valueize) (gimple_assign_rhs2 (stmt));
if (TREE_CODE (op0) == ADDR_EXPR
&& TREE_CODE (op1) == INTEGER_CST)
{
tree off = fold_convert (ptr_type_node, op1);
return build1_loc
(loc, ADDR_EXPR, TREE_TYPE (op0),
fold_build2 (MEM_REF,
TREE_TYPE (TREE_TYPE (op0)),
unshare_expr (op0), off));
}
}
Which appears to eventually invoke fold_binary_loc () and simply lump
it as a gep codeneric char * MEMref.
Is there a place we currently do this that would be more precise? Or
does this need enhancing? or what is the best way to proceed
Andrew
