This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Nathan Sidwell <nathan at acm dot org>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 2 Dec 2018 14:07:22 +0100
- Subject: Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)
- References: <20181129215227.GV12380@tucnak> <5c68bcdb-0cbc-6044-f6c4-fe241a307cf5@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sat, Dec 01, 2018 at 07:11:08PM -0500, Jason Merrill wrote:
> > On the following testcase, build_conditional_expr_1 tries hard to make sure
> > that if both arguments are xvalue_p (or one is and the other throw) the
> > result is still xvalue_p. But, later on we call unary_complex_lvalue,
> > which does rationalize_conditional_expr which changes it from
> > cond ? x : y to *(cond ? &x : &y) and that change turns something formerly
> > xvalue_p into newly lvalue_p.
> >
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> > ok for trunk?
> >
> > 2018-11-29 Jakub Jelinek <jakub@redhat.com>
> >
> > PR c++/88103
> > * typeck.c (unary_complex_lvalue): If a COND_EXPR is xvalue_p, make
> > sure the result is as well.
> >
> > * g++.dg/cpp0x/rv-cond3.C: New test.
> >
> > --- gcc/cp/typeck.c.jj 2018-11-27 09:48:58.506103668 +0100
> > +++ gcc/cp/typeck.c 2018-11-29 21:00:33.900636750 +0100
> > @@ -6503,7 +6503,16 @@ unary_complex_lvalue (enum tree_code cod
> > /* Handle (a ? b : c) used as an "lvalue". */
> > if (TREE_CODE (arg) == COND_EXPR
> > || TREE_CODE (arg) == MIN_EXPR || TREE_CODE (arg) == MAX_EXPR)
> > - return rationalize_conditional_expr (code, arg, tf_warning_or_error);
> > + {
> > + tree ret = rationalize_conditional_expr (code, arg, tf_warning_or_error);
> > + /* Preserve xvalue kind. */
> > + if (xvalue_p (arg))
> > + {
> > + tree reftype = cp_build_reference_type (TREE_TYPE (arg), true);
> > + ret = cp_convert (reftype, ret, tf_warning_or_error);
>
> Is there a reason not to use the 'move' function here?
That doesn't work at all. move doesn't call cp_convert, but
build_static_cast (though for the same reference && type).
But while cp_convert only adds NOP_EXPR around it, build_static_cast adds
a target_expr, addr_expr around that, nop_expr cast to the reference && type
and finally indirect_ref that the caller doesn't expect, because it adds it
by itself, e.g. in
2424 if (temp)
2425 object = cp_build_fold_indirect_ref (temp);
Jakub