From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id DCB773858403 for ; Mon, 12 Sep 2022 20:27:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DCB773858403 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663014453; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xfav9V4UThdqSC0QjB5DmYu2EwlK+PLMHm5EWOu93jg=; b=UbJMh5gcunOAtCC3w7vdVmZJ4sJy0hwANbi+zDbysqZG+BoPOJRUjR2/iOltebH+wdW3S3 BpstMni2+LJvJSnwUDfanG6EdwB2IlRiYl1th7k80AeQLKl0M8rSKYL6fkCiJuV2CHPjCn j2pQUO5UR1KhFedfTjnMqNQzwmYahsg= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-17-aw7FhxPQNU2Vok6kCtBTUA-1; Mon, 12 Sep 2022 16:27:32 -0400 X-MC-Unique: aw7FhxPQNU2Vok6kCtBTUA-1 Received: by mail-qk1-f199.google.com with SMTP id j13-20020a05620a288d00b006be7b2a758fso8282286qkp.1 for ; Mon, 12 Sep 2022 13:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=xfav9V4UThdqSC0QjB5DmYu2EwlK+PLMHm5EWOu93jg=; b=6xjAFt+ZaxhaxCi/hhpP+0E1VfGkVwEBya1BTS8SjyUfcJlyfLOi5i4trZonHcNL69 ae2jCTLFcBapYMecAA1O8sIEUL7HJPLpxrhOvLBjsBIaAMVtnS9Ph0cJsxGRFmayqNj7 gxzavQSTqtj5pedcMNs07JFoiurkVSUAjdFPoWQN3g07Eym2mHHtM1ZxerGoU10CkRby 1+YgZAmkl647uZLcDbE0Jqwdb3sDeM6jAp4K8GxKEhUJOaWDxtHPMuw4SjbPQEMNdSeD 2CglIZoSiYh8Ud3EB/ns+EGK6UIDviaYknXENOT8Y0Ja7C10U6i7Fmuq1We7qLg3QFPz iZ7w== X-Gm-Message-State: ACgBeo3LAXxaWDRcyyytX2u7XTxT5MZsk9wWNJJZ5A0+U4w4TWjQsVfV QOVxxc0J4d/5T0mA/pL0WGeHhajVut7k5AdQS4FjhtPeCRbOczCk47q3+2B7DJIsVO3gGcVH/V7 StikJl8Vs9NaCRai+Ag== X-Received: by 2002:a05:620a:488e:b0:6bb:3f84:d175 with SMTP id ea14-20020a05620a488e00b006bb3f84d175mr20404996qkb.587.1663014452035; Mon, 12 Sep 2022 13:27:32 -0700 (PDT) X-Google-Smtp-Source: AA6agR4lYCJa3ZDKfjK64CQFAh8S+rKGzr5GwOsD/tm/0yL9Kf2GB3iNnIPYA4gTTMSICnJDpaBGTg== X-Received: by 2002:a05:620a:488e:b0:6bb:3f84:d175 with SMTP id ea14-20020a05620a488e00b006bb3f84d175mr20404978qkb.587.1663014451638; Mon, 12 Sep 2022 13:27:31 -0700 (PDT) Received: from [192.168.1.101] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id j10-20020ac806ca000000b0035a7070e909sm7065081qth.38.2022.09.12.13.27.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Sep 2022 13:27:31 -0700 (PDT) Message-ID: <3cfe2791-914e-1b7c-b874-2fcc34f2c240@redhat.com> Date: Mon, 12 Sep 2022 16:27:27 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165] To: Marek Polacek Cc: GCC Patches References: <20220903164200.17908-1-polacek@redhat.com> <9f9f6d62-c3c8-083e-d30d-808076c01eca@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/8/22 18:54, Marek Polacek wrote: > On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote: >> On 9/3/22 12:42, Marek Polacek wrote: >>> This patch implements https://wg21.link/p2266, which, once again, >>> changes the implicit move rules. Here's a brief summary of various >>> changes in this area: >>> >>> r125211: Introduced moving from certain lvalues when returning them >>> r171071: CWG 1148, enable move from value parameter on return >>> r212099: CWG 1579, it's OK to call a converting ctor taking an rvalue >>> r251035: CWG 1579, do maybe-rvalue overload resolution twice >>> r11-2411: Avoid calling const copy ctor on implicit move >>> r11-2412: C++20 implicit move changes, remove the fallback overload >>> resolution, allow move on throw of parameters and implicit >>> move of rvalue references >>> >>> P2266 enables the implicit move for functions that return references. This >>> was a one-line change: check TYPE_REF_P. That is, we will now perform >>> a move in >>> >>> X&& foo (X&& x) { >>> return x; >>> } >>> >>> P2266 also removes the fallback overload resolution, but this was >>> resolved by r11-2412: we only do convert_for_initialization with >>> LOOKUP_PREFER_RVALUE in C++17 and older. >> >> I wonder if we want to extend the current C++20 handling to the older modes >> for GCC 13? Not in this patch, but as a followup. >> >>> P2266 also says that a returned move-eligible id-expression is always an >>> xvalue. This required some further short, but nontrivial changes, >>> especially when it comes to deduction, because we have to pay attention >>> to whether we have auto, auto&& (which is like T&&), or decltype(auto) >>> with (un)parenthesized argument. In C++23, >>> >>> decltype(auto) f(int&& x) { return (x); } >>> auto&& f(int x) { return x; } >>> >>> both should deduce to 'int&&' but >>> >>> decltype(auto) f(int x) { return x; } >>> >>> should deduce to 'int'. A cornucopia of tests attached. I've also >>> verified that we behave like clang++. >>> >>> xvalue_p seemed to be broken: since the introduction of clk_implicit_rval, >>> it cannot use '==' when checking for clk_rvalueref. >>> >>> Since this change breaks code, it's only enabled in C++23. In >>> particular, this code will not compile in C++23: >>> >>> int& g(int&& x) { return x; } >> >> Nice that the C++20 compatibility is so simple! >> >>> because x is now treated as an rvalue, and you can't bind a non-const lvalue >>> reference to an rvalue. >>> >>> There's one FIXME in elision1.C:five, which we should compile but reject >>> with "passing 'Mutt' as 'this' argument discards qualifiers". That >>> looks bogus to me, I think I'll open a PR for it. >> >> Let's fix that now, I think. > > Can of worms. The test is > > struct Mutt { > operator int*() &&; > }; > > int* five(Mutt x) { > return x; // OK since C++20 because P1155 > } > > 'x' should be treated as an rvalue, therefore the operator fn taking > an rvalue ref to Mutt should be used to convert 'x' to int*. We fail > because we don't treat 'x' as an rvalue because the function doesn't > return a class. So the patch should be just > > --- a/gcc/cp/typeck.cc > +++ b/gcc/cp/typeck.cc > @@ -10875,10 +10875,7 @@ check_return_expr (tree retval, bool *no_warning) > Note that these conditions are similar to, but not as strict as, > the conditions for the named return value optimization. */ > bool converted = false; > - tree moved; > - /* This is only interesting for class type. */ > - if (CLASS_TYPE_P (functype) > - && (moved = treat_lvalue_as_rvalue_p (retval, /*return*/true))) > + if (tree moved = treat_lvalue_as_rvalue_p (retval, /*return*/true)) > { > if (cxx_dialect < cxx20) > { > > which fixes the test, but breaks a lot of middle-end warnings. For instance > g++.dg/warn/nonnull3.C, where the patch above changes .gimple: > > bool A::foo (struct A * const this, <<< Unknown tree: offset_type >>> p) > { > - bool D.2146; > + bool D.2150; > > - D.2146 = p != -1; > - return D.2146; > + p.0_1 = p; > + D.2150 = p.0_1 != -1; > + return D.2150; > } > > and we no longer get the warning. I thought maybe I could undo the implicit > rvalue conversion in cp_fold, when it sees implicit_rvalue_p, but that didn't > work. So currently I'm stuck. Should we try to figure this out or push aside? Can you undo the implicit rvalue conversion within check_return_expr, where we can still refer back to the original expression? Or avoid the rvalue conversion if the return type is scalar? Did you see my comments in the body of the patch? Jason