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
