From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2870 invoked by alias); 2 Dec 2018 00:11:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 2793 invoked by uid 89); 2 Dec 2018 00:11:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.2 required=5.0 tests=BAYES_50,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=88103, 33900636750, thusly, typeckcjj X-HELO: mail-qt1-f178.google.com Received: from mail-qt1-f178.google.com (HELO mail-qt1-f178.google.com) (209.85.160.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 02 Dec 2018 00:11:33 +0000 Received: by mail-qt1-f178.google.com with SMTP id n32so10039817qte.11 for ; Sat, 01 Dec 2018 16:11:33 -0800 (PST) Return-Path: Received: from [192.168.1.132] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id o48sm6123276qtb.87.2018.12.01.16.11.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Dec 2018 16:11:30 -0800 (PST) Subject: Re: [C++ PATCH] Fix xvalue COND_EXPR handling (PR c++/88103) To: Jakub Jelinek , Nathan Sidwell Cc: gcc-patches@gcc.gnu.org References: <20181129215227.GV12380@tucnak> From: Jason Merrill Message-ID: <5c68bcdb-0cbc-6044-f6c4-fe241a307cf5@redhat.com> Date: Sun, 02 Dec 2018 00:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20181129215227.GV12380@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00026.txt.bz2 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 > > 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