From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by sourceware.org (Postfix) with ESMTPS id ADF3438618D7 for ; Sat, 27 Feb 2021 00:18:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ADF3438618D7 Received: by mail-qv1-xf33.google.com with SMTP id dr7so5424295qvb.1 for ; Fri, 26 Feb 2021 16:18:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lPrgA81SyuMKLT9/GNOcofnlXKW0Pu7wnacCiSCV3J4=; b=SnSTnEuZxgf7hbNuUQaqOgtsqPylm3acDl1VWSNXg6iCSQFH67z0xVOhmt/s8tFjP3 gMaJDwDLI6uTjGOHtCjGADpfWaUlgadM0CKStwceB/OKglsA//qGAml52ltSFbhgOFIw CIxOOFksRqpXsP39O7vMKGvmSYRr9ZtA0QPv2VNELSbO2WUZSrU8l3ueGULtQVK1Hp5Q pymGTiZaKijSs875IBV8UmcotGyWT2tGJ7zIumW51g4/0Bfg8BrEn8LkjkXxU93quVSy FlwyN0yx+seoGtIwbxxumMOkxloTBXivRTlaOtsDVsqNozemfqcQX/54iLHzuNmml+UX CgfA== X-Gm-Message-State: AOAM531rfZWfu70oiYUJi0nCHeEMXTjh+oBrd72h6yhbmO/oMncnKMax OyosHt+jvV9UkNRWDRix4mc7IUBLDpf9DipSY1s= X-Google-Smtp-Source: ABdhPJw+DDvxjtcsvJ467VkV1GUpVLbTh/S/gWjGQVm03LOErBfQCWE2eJM/X3uYJc8628Aw0j22Ao/Hhh8hJlfHfAY= X-Received: by 2002:a0c:b286:: with SMTP id r6mr5408689qve.40.1614385124349; Fri, 26 Feb 2021 16:18:44 -0800 (PST) MIME-Version: 1.0 References: <1968544.UC5HiB4uFJ@tjmaciei-mobl1> <3242307.1ZfphE9myc@tjmaciei-mobl1> <1642718.4M2VOOmbIH@tjmaciei-mobl1> In-Reply-To: <1642718.4M2VOOmbIH@tjmaciei-mobl1> From: Ville Voutilainen Date: Sat, 27 Feb 2021 02:18:33 +0200 Message-ID: Subject: Re: C++2a synchronisation inefficient in GCC 11 To: Thiago Macieira Cc: Jonathan Wakely , Thomas Rodgers , "libstdc++" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2021 00:18:55 -0000 On Sat, 27 Feb 2021 at 02:11, Thiago Macieira wrote: > > On Friday, 26 February 2021 15:58:01 PST Ville Voutilainen wrote: > > > Should they also prevent people from compiling their code with GCC 11, > > > which will define the macro and does support "-std=c++20"? > > > > Yes, if there's an implementation bug in GCC 11 that renders the GCC > > 12 implementation incompatible. > > This is not new. > > One would expect that implementation bugs -- not design flaws -- do not affect > the entire functionality. And in most inline code, that is not a big deal > since the operation was still achieved one way or the other. > > What we're talking about here makes the entire set of classes unsuitable for > consumption and dangerous, with no way to programmatically determine when > they've become suitable. My worry is not that someone will rush to use them in > 2021. My worry is that well-tested code in 2024-2025 breaks because people are > using a mix of systems that includes Ubuntu 22.04. There's nothing new in that either. I do, however, wonder how dangerous using the current implementation actually is? Anyhoo, almost regardless of that, we have had situations like that before. While we don't exactly want to repeat them (std::regex in.. gcc8? comes to mind here), I'm not entirely convinced that we are talking about a showstopper problem here. > > No general one. Here we are talking about implementation bugs; > > feature-testing macros are not > > trying to cover those. And in the sunshine cases where we don't have > > bugs or binary breaks, > > defining the macros early is fine, so we're not going to postpone > > defining them, in the hypothetical > > event that someone might suggest that. > > Fair enough, but we know we are not in the sunshine case. We know now, before > the release, that it WILL change and cause silent incompatibilities. Does that > change the conclusion? Do tell me what those silent incompatibilities really are. If they're differences in inlined code baked into client applications, I'm not sure I see what's so earth-shattering there. > How about the other way around: only enable the new, experimental code if the > user defines _GLIBCXX_I_WANT_EXPERIMENTAL before the #includes? That seems drastic. We wouldn't get pretty much any use coverage of any new code, and that would just sweep the rug from under the whole idea of feature-testing macros, half of which is allowing bold users to adopt new facilities early. Now they would need to fall back to seventeen different implementation-specific ways to opt in to that adoption, which takes us back a decade. Please explain how your concerns about atomic waits are *anywhere near* the cost of doing that?