On 12/16/25 13:00, Jakub Jelinek wrote:
On Tue, Dec 16, 2025 at 10:34:55AM -0500, Andrew MacLeod wrote:
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]
This is highly undesirable in the early optimizations, it is
a serious security problem in some cases.
E.g. tree-ssa-sccvn.cc has several spots guarded with
(cfun->curr_properties & PROP_objsz)
to avoid this kind of optimizations happening before the first objsz
pass.
Jakub
I opened a PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123160 with
a simple testcase which doesn't depend on any of my points to code and
produces incorrect results.
In it,
r_4 = &a.a[4];
_1 = r_4 + 2;
_2 = memset (_1, 98, 2);
Is transformed very early (in ccp1) to
_2 = memset (&MEM <char> [(void *)&a + 6B], 98, 2);
This does happen after early_objsz, for what that's worth.
Andrew
