Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103)

[Jason Merrill <jason@redhat.com>]

On 12/2/18 8:07 AM, Jakub Jelinek wrote:
> 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);

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.

Jason