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 C90B93858D38 for ; Wed, 12 Oct 2022 20:50:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C90B93858D38 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=1665607849; 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=lGukcqKflelxai4wASKp6hMW1ibWtJnhDCZ/d0DkiZA=; b=UYRaPneZUZsPCDkH/ZsoeII1mxeHefpv9tD7zmqN0NZwbGzKB6EUSKevYNDw61rqWLp6cJ CIv/v3xnN5KSNBBp+HswOPO8bvpfhAw7aM+R/n51W61HdXYJFvc48rXzlbS9zzjM8bU7fz iOC8Tb0vlQpS3Ss7M6R/hoK8yd+DDO8= 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-412-fp7DySuTPbuLcrzAmlZB4g-1; Wed, 12 Oct 2022 16:50:48 -0400 X-MC-Unique: fp7DySuTPbuLcrzAmlZB4g-1 Received: by mail-qk1-f199.google.com with SMTP id f12-20020a05620a408c00b006ced53b80e5so15323730qko.17 for ; Wed, 12 Oct 2022 13:50:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lGukcqKflelxai4wASKp6hMW1ibWtJnhDCZ/d0DkiZA=; b=iNEMDCElvkc1XfJdbMJdK1Lm6mP+/+HRLZZiA80+ACvJ4DeJSpngcrBMpzjuzxmTaq XBPV7F6XtGeoR+cTbGwDUWIYU7tnOYG//pByi8K2sTiWgTeSIoBN3wW0Ymi9KzNQCrOu vEBxxWLK/zW24JTLbwTSt/PHtj0Af9Q3kJv/mH+BVXPs36dj4eMWFVzQ9VLaX0HfETIn WKUTqusHTu7ef/gtCYDNfE8+q0ElvHkxnQfF5qhGMrG/eVXVHtckarnpkNm5gSZVpxX5 2mhwMTC8XinpJn2YeBV8Q9YKaUJg9cyBVQUxfE/ZIW/yT/il/rN/eJeCLXkRUvwfR2JF b5iw== X-Gm-Message-State: ACrzQf2aBxQQMjMxajTsIzker3DKXtKDlxNXsvB1V+3pjZcRRHAuJkSD Z6BO5z9lAL3Q/umnwn08vvgQn/nzsc9zSuqhUv40bqr2H3wtNGmcByuzRvtNcgCbjxnuChJCPrM NAOQwSFvsY0Um21YpmwgX1sovroLx2T1vCw== X-Received: by 2002:a05:620a:13f2:b0:6ec:597f:eda6 with SMTP id h18-20020a05620a13f200b006ec597feda6mr13280334qkl.287.1665607847808; Wed, 12 Oct 2022 13:50:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM67dhVHJcatKUI8W5fnfQ6blzA3Ga+ucgOtR9shELaE0Wt3AEZFH9UADVyVESW79d8NBnF/nxVdkduUcytPaIY= X-Received: by 2002:a05:620a:13f2:b0:6ec:597f:eda6 with SMTP id h18-20020a05620a13f200b006ec597feda6mr13280316qkl.287.1665607847506; Wed, 12 Oct 2022 13:50:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 12 Oct 2022 21:50:36 +0100 Message-ID: Subject: Re: [wwwdocs] porting_to: Two-stage overload resolution for implicit move removed To: Marek Polacek Cc: GCC Patches , Jason Merrill X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 Wed, 12 Oct 2022 at 20:39, Marek Polacek wrote: > > As I promised in > , > I'd like to update our GCC 13 porting_to.html with the following note. > > Does this look OK to commit? Thanks, > > diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html > index 84a00f21..243ed29d 100644 > --- a/htdocs/gcc-13/porting_to.html > +++ b/htdocs/gcc-13/porting_to.html > @@ -42,5 +42,57 @@ be included explicitly when compiled with GCC 13: > > > > +

Two-stage overload resolution for implicit move removed

> +

> +GCC 13 removed the two-stage overload resolution when performing > +implicit move, whereby the compiler does two separate overload resolutions: > +one treating the operand as an rvalue, and then (if that resolution fails) > +another one treating the operand as an lvalue. In the standard this was > +introduced in C++11 and implemented in gcc in > + > +r251035. In > + > +r11-2412, the fallback overload resolution was disabled in C++20 (but > +not in C++17). Then C++23 P2266 > +removed the fallback overload resolution, and changed the implicit move > +rules once again. > +

> +

> +The two overload resolutions approach was complicated and quirky, so users > +should transition to the newer model. This change means that code that > +previously didn't compile in C++17 will now compile, for example:

> + > +

> +   struct S1 { S1(S1 &&); };
> +   struct S2 : S1 {};
> +
> +   S1
> +   f (S2 s)
> +   {
> +     return s; // OK, derived-to-base, use S1::S1(S1&&)
> +   }
> +
> + > +

> +And conversely, code that used to work in C++17 may not compile anymore: > +

> + > +

> +   struct W {
> +     W();
> +   };
> +
> +   struct F {
> +     F(W&);
> +     F(W&&) = delete;
> +   };
> +
> +   F fn ()
> +   {
> +     W w;
> +     return w; // use w as rvalue -> use of deleted function F::F(W&&)

Deleted move constructors are an abomination, and should never occur
in real code. I'm not sure using one even in an example like this
should be encouraged. The example added by P2266 to Annex D is more
realistic (and actually broke a libstdc++ test):

X& foo(X&& x) { return x; }



> +   }
> +
> + > > >