This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 11/29/18 4:52 PM, Jakub Jelinek 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  <>

	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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]