On Wed, Oct 23, 2024 at 12:27:32PM -0400, Jason Merrill wrote:
> On 10/22/24 2:17 PM, Jakub Jelinek wrote:
> > The following testcase shows that the previous
> > get_member_function_from_ptrfunc
> > changes weren't sufficient and we still have cases where
> > -fsanitize=undefined with pointers to member functions can cause wrong code
> > being generated and related false positive warnings.
> >
> > The problem is that save_expr doesn't always create SAVE_EXPR, it can skip
> > some invariant arithmetics and in the end it could be really large
> > expressions which would be evaluated several times (and what is worse, with
> > -fsanitize=undefined those expressions then can have SAVE_EXPRs added to
> > their subparts for -fsanitize=bounds or -fsanitize=null or
> > -fsanitize=alignment instrumentation). Tried to just build1 a SAVE_EXPR
> > + add TREE_SIDE_EFFECTS instead of save_expr, but that doesn't work either,
> > because cp_fold happily optimizes those SAVE_EXPRs away when it sees
> > SAVE_EXPR operand is tree_invariant_p.
>
> Hmm, when is that be a problem? I wouldn't expect instance_ptr to be
> tree_invariant_p.
E.g. TREE_READONLY !TREE_SIDE_EFFECTS ARRAY_REF (with some const array first
operand and some VAR_DECL etc. second operand).
That is tree_invariant_p, but when -fsanitize=bounds attempts to instrument
that, it sees the index is a VAR_DECL and so creates SAVE_EXPR for it.
Jakub
