From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25362 invoked by alias); 11 Jan 2019 18:55:15 -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 25352 invoked by uid 89); 11 Jan 2019 18:55:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=indirection X-HELO: mail-qt1-f196.google.com Received: from mail-qt1-f196.google.com (HELO mail-qt1-f196.google.com) (209.85.160.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Jan 2019 18:55:13 +0000 Received: by mail-qt1-f196.google.com with SMTP id p17so19960821qtl.5 for ; Fri, 11 Jan 2019 10:55:13 -0800 (PST) Return-Path: Received: from [192.168.1.115] (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 b134sm34868487qkg.78.2019.01.11.10.55.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jan 2019 10:55:10 -0800 (PST) Subject: Re: C++ PATCH for c++/88692 - -Wredundant-move false positive with *this To: Marek Polacek Cc: GCC Patches References: <20190107212919.GF28316@redhat.com> <20190111160914.GV28316@redhat.com> From: Jason Merrill Message-ID: <238905c0-0a81-35e1-fd6b-7567eb677981@redhat.com> Date: Fri, 11 Jan 2019 18:55: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: <20190111160914.GV28316@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00651.txt.bz2 On 1/11/19 11:09 AM, Marek Polacek wrote: > On Mon, Jan 07, 2019 at 04:59:14PM -0500, Jason Merrill wrote: >> On 1/7/19 4:29 PM, Marek Polacek wrote: >>> This patch fixes bogus -Wredundant-move warnings reported in 88692 and 87882. >>> >>> To quickly recap, this warning is supposed to warn for cases like >>> >>> struct T { }; >>> >>> T fn(T t) >>> { >>> return std::move (t); >>> } >>> >>> where NRVO isn't applicable for T because it's a parameter, but it's >>> a local variable and we're returning, so C++11 says activate move >>> semantics, so the std::move is redundant. But, as these testcases show, >>> we're failing to realize that that is not the case when returning *this, >>> which is disguised as an ordinary PARM_DECL, and treat_lvalue_as_rvalue_p >>> was fooled by that. >> >> Hmm, the function isn't returning 'this', it's returning '*this'. I guess >> what's happening is that in order to pass *this to the reference parameter >> of move, we end up converting it from pointer to reference by NOP_EXPR, and >> the STRIP_NOPS in maybe_warn_pessimizing_move throws that away so that it >> then thinks we're returning 'this'. I expect the same thing could happen >> with any parameter of pointer-to-class type. > > You're right, I didn't realize that we warned even for parameters of pointer-to-class > types. So why don't we disable the warning for PARM_DECLs with pointer types? std::move is certainly redundant for parms of pointer type (or other scalar type), so we might still want to warn about 'return std::move(this)'. The problem here is that we're discarding the indirection, so we aren't actually considering the returned expression. Is the STRIP_NOPS really necessary? It seems we shouldn't remove a NOP_EXPR from pointer to reference. Jason