From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6F3FB3857022; Thu, 25 Feb 2021 23:27:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F3FB3857022 From: "thiago at kde dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/99277] New: C++2a synchronisation is inefficient in GCC 11 and can't be fixed later Date: Thu, 25 Feb 2021 23:27:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: thiago at kde dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 23:27:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99277 Bug ID: 99277 Summary: C++2a synchronisation is inefficient in GCC 11 and can't be fixed later Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org Target Milestone: --- Requesting that this be treated as a blocker for GCC 11. Detailed post: https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html Summary: Since everything in this implementation is inline and, once released, it wi= ll tie our hands until the next ABI break (libstdc++.so.7). And no, inline namespaces and ABI tags are no different than ABI breaks, they only make the ABI break more or less silent in the process. Here's a summary of the findings: 1) everything is inline 2) futex code is still behind a lot of code calling into std::_Hash_bytes 3) other int-sized (incl. enums) atomics don't use futex 4) std::latch and std::counting_semaphore defaults preclude from using futex on Linux 5) std::barrier implementation also uses a type that futex(2) can't handle=