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.133.124]) by sourceware.org (Postfix) with ESMTPS id 33C4D385829F for ; Tue, 20 Sep 2022 18:21:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 33C4D385829F 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=1663698083; 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: in-reply-to:in-reply-to:references:references; bh=YBuAX715XKbeQP/UevmpfE5kF+x0CmzAyjgg2DWSAA8=; b=i/KKx2fBXz56XqBKqEBgCfpTKUzZzGX5p/HIa4lZzCwDvDxDT+jmNJR4td0tjqb9wNtu0l 0YDvG1i+kBqDyBBY4/2iXxYBzduEYm7rX74XxD4ektbolJpPIyKwez+29RRUj0ZNqNNoEf KbrdYbeDqGDVyefLXRMTzAuDES5ZSps= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-470-q8VpYA7NMPyY9GBrtlNvdQ-1; Tue, 20 Sep 2022 14:21:22 -0400 X-MC-Unique: q8VpYA7NMPyY9GBrtlNvdQ-1 Received: by mail-qt1-f198.google.com with SMTP id cb22-20020a05622a1f9600b0035bb51792d2so2442478qtb.5 for ; Tue, 20 Sep 2022 11:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=YBuAX715XKbeQP/UevmpfE5kF+x0CmzAyjgg2DWSAA8=; b=Nxft9Rds/NINfBLT8gffoveBML+9f8xyYeTgEyUf2Q1B9rvsjpOBWLlsxHXTl+r9Km 0YiHBDK5hiGMu2ZOhsm1e2Mlr9EeXrFcUxNZDgmJslJDibknoQk/IkPa0yAqGHwT/2pU 0Ox59K1FAoDqh0x7I88goeOiwtOOXHDSsnTRhC7TJa7GkUhJSEcEnpW6uETcHsuiXeXu WO5B8BvphZVRoyYIVoRqHE7NOmg/SWIyWI0qsZFb93oL6Rdt2awpFJ4xXGKwnnhVM8xf xnb/CAc9OObbj4H6015mQsC+tmh39tXMZrGqpSYOyfKS3BeszHYvfHTJntdHB52RcXhE aWwg== X-Gm-Message-State: ACrzQf3Z/2tpy9OU3BUAsqahWVdc/AzuIcXB0Pn8dx+8/RLdyWXeuID7 y8qPKmd63nICwK2wi7lX5/Aqu/TK7cFoKMLv2D+ViRimUlP7ak1INF4KXncWpsW0MQQmC/+nNqy cDP0smry6vp1OGmA14g== X-Received: by 2002:a05:620a:2b95:b0:6ce:5dca:96da with SMTP id dz21-20020a05620a2b9500b006ce5dca96damr17379551qkb.174.1663698081208; Tue, 20 Sep 2022 11:21:21 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4cR/jn5ggmRZvViI6OVr2wLNEoBucfsZVzdDFFhZgSfy3MbpJxZ6E+izZfuaO16+kF4QQtxw== X-Received: by 2002:a05:620a:2b95:b0:6ce:5dca:96da with SMTP id dz21-20020a05620a2b9500b006ce5dca96damr17379540qkb.174.1663698080936; Tue, 20 Sep 2022 11:21:20 -0700 (PDT) Received: from redhat.com (2603-7000-9500-2e39-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:2e39::1db4]) by smtp.gmail.com with ESMTPSA id m22-20020a05620a24d600b006b5bf5d45casm357181qkn.27.2022.09.20.11.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 11:21:20 -0700 (PDT) Date: Tue, 20 Sep 2022 14:21:18 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH] c++: Implement C++23 P2266R1, Simpler implicit move [PR101165] Message-ID: References: <20220903164200.17908-1-polacek@redhat.com> <9f9f6d62-c3c8-083e-d30d-808076c01eca@redhat.com> <3cfe2791-914e-1b7c-b874-2fcc34f2c240@redhat.com> MIME-Version: 1.0 In-Reply-To: <3cfe2791-914e-1b7c-b874-2fcc34f2c240@redhat.com> User-Agent: Mutt/2.2.7 (2022-08-07) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP 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 Mon, Sep 12, 2022 at 04:27:27PM -0400, Jason Merrill wrote: > 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? I responded in the email I just sent so that we can have a single thread. Marek