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 34BE83858C2D for ; Thu, 8 Sep 2022 22:54:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34BE83858C2D 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=1662677651; 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=nVXNva6K3l6HuECe81EeTpK0yRJYRG54iVHM0ojlK70=; b=Ax8CgEBLE0P0R997WG/HR5JUqxMH+hGe9Q1SyaEj2uWQpfx5FtRXxrrhyVowvYdcGUduJn 3Vl67Z2FiBUWIKLgcbvl53D7qWF+5MXigocBeBhdJL3WXZo5H9/QKxgMRF6YgSuPgPtdom yIrtyE6+7V1EDHLuDxsMuKzyN8ODT2w= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-646-OVEPTdNcP4yEGwmHKb0sEQ-1; Thu, 08 Sep 2022 18:54:09 -0400 X-MC-Unique: OVEPTdNcP4yEGwmHKb0sEQ-1 Received: by mail-qv1-f71.google.com with SMTP id y7-20020ad45307000000b004ac7fd46495so1937269qvr.23 for ; Thu, 08 Sep 2022 15:54:09 -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=nVXNva6K3l6HuECe81EeTpK0yRJYRG54iVHM0ojlK70=; b=KaWend4zFMBvCGGXTvuVedjhD5x9metW0Zl7mGmWiF5jQBLjWpO/uoyfxPmHM+OHUf SWwEJvGzdht95fJZusFB0BKleo2Wo3bpLKdaB3xQxW65OW1tlHfg1mBJ+hcJavAlegh8 z3XMYkmiNafcU4/4Uug5obF4GOPJqf/76xAQ33V39PJPSLmtRn5/9jbPzT39hngYcJRI /XlspOOHQPZbLzRGXLKWaRJK3r9GUbVfDuJc+R0aTGhnJGcmNMGZOF9Zzw6QSh0HviM+ OkcIJ3lERTqUopZbPGyW8o9TGFVLIi4pUoF2YexmS4DSWskUUinI5kIa56EIPP/Jvgzh 8O5g== X-Gm-Message-State: ACgBeo0ZoCYh5wJ9Afa6mRjipy+1qlrDlOzJXkw+IDyB6g42zBivEV/c vmyjicdB9e6BwU9UaY5SCvRo9DgF4SRhgq3UDPuFyMVTi101e4Knz5M6tGJt8HUtMXcEVWS0pqB 2BPkOEBycJpzPEKqnvA== X-Received: by 2002:a05:6214:19c5:b0:498:fcc3:5deb with SMTP id j5-20020a05621419c500b00498fcc35debmr9804299qvc.128.1662677649334; Thu, 08 Sep 2022 15:54:09 -0700 (PDT) X-Google-Smtp-Source: AA6agR5q0ZfNxcHXjQw0w2j0vUkFTv5aPWdqqm/KOfJ8rIsEYufG2BOe8OroYdM/RZGOFDTtN77swQ== X-Received: by 2002:a05:6214:19c5:b0:498:fcc3:5deb with SMTP id j5-20020a05621419c500b00498fcc35debmr9804292qvc.128.1662677649062; Thu, 08 Sep 2022 15:54:09 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::e531]) by smtp.gmail.com with ESMTPSA id t4-20020a05622a180400b0035a6b89412bsm346724qtc.46.2022.09.08.15.54.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Sep 2022 15:54:08 -0700 (PDT) Date: Thu, 8 Sep 2022 18:54:06 -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> MIME-Version: 1.0 In-Reply-To: <9f9f6d62-c3c8-083e-d30d-808076c01eca@redhat.com> User-Agent: Mutt/2.2.6 (2022-06-05) 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.7 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,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 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? Marek