This is the mail archive of the
mailing list for the GCC project.
Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Nathan Sidwell <nathan at acm dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 3 Dec 2018 16:58:10 -0500
- Subject: Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)
- References: <20181129215227.GV12380@tucnak> <email@example.com> <20181202130722.GP12380@tucnak> <firstname.lastname@example.org> <20181203213648.GC12380@tucnak>
On Mon, Dec 3, 2018 at 4:36 PM Jakub Jelinek <email@example.com> wrote:
> On Mon, Dec 03, 2018 at 02:44:32PM -0500, Jason Merrill wrote:
> > > > 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);
> > So the caller is trying to take the address of the COND_EXPR, which should
> > have POINTER_TYPE. And then indirecting that gives an lvalue, as it should.
> > The bug is in the caller, build_class_member_access_expr.
> So like this then (if it passes bootstrap/regtest)? Seems to fix the
> 2018-12-03 Jakub Jelinek <firstname.lastname@example.org>
> PR c++/88103
> * typeck.c (build_class_member_access_expr): If unary_complex_lvalue
> turned xvalue_p into non-xvalue_p, call move on it.
> * g++.dg/cpp0x/rv-cond3.C: New test.