On Tue, Mar 21, 2017 at 03:27:02PM -0400, Jason Merrill wrote:
> OK.
>
> On Tue, Mar 21, 2017 at 11:38 AM, Marek Polacek <pola...@redhat.com> wrote:
> > This patch fixes a bogus maybe-uninitialized warning reported in the PR.
> > The issue is that we're not able to fold away useless CLEANUP_POINT_EXPRs,
> > as e.g. in
> > if (<<cleanup_point 0>>)
> > // bogus warning
> > Here, the cleanup_point was built as <<cleanup_point 0 && (i = 4) != 0>>,
> > which cp_fold_r reduces to <<cleanup_point 0>>, but leaves it as that and
> > passes it to the gimplifier.
> >
> > Jakub suggested handling this in cp_fold. fold_build_cleanup_point_expr
> > says
> > that "if the expression does not have side effects then we don't have to
> > wrap
> > it with a cleanup point expression", so I think the following should be
> > safe.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2017-03-21 Marek Polacek <pola...@redhat.com>
> >
> > PR c++/80119
> > * cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the
> > expression
> > doesn't have side effects.
> >
> > * g++.dg/warn/Wuninitialized-9.C: New test.
> >
> > diff --git gcc/cp/cp-gimplify.c gcc/cp/cp-gimplify.c
> > index ebb5da9..b4319ca 100644
> > --- gcc/cp/cp-gimplify.c
> > +++ gcc/cp/cp-gimplify.c
> > @@ -2056,6 +2056,14 @@ cp_fold (tree x)
> > code = TREE_CODE (x);
> > switch (code)
> > {
> > + case CLEANUP_POINT_EXPR:
> > + /* Strip CLEANUP_POINT_EXPR if the expression doesn't have side
> > + effects. */
> > + r = cp_fold (TREE_OPERAND (x, 0));
Can CLEANUP_POINT_EXPR be an lvalue? If not, maybe cp_fold_rvalue instead?
> > + if (!TREE_SIDE_EFFECTS (r))
> > + x = r;
> > + break;
> > +
Jakub
