On 11/29/18 4:52 PM, Jakub Jelinek wrote:
Hi!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 <ja...@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? Jason
