From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5877E3858C53; Mon, 8 May 2023 16:39:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5877E3858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683563966; bh=DbitEKHkSVm4PcLK2+BBaRGc/mq/muwcpD9jrgUtqto=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XW+UT/wZ5BCXD2omwGRkSGihJEhzzFtAB6CW/vHDCxKnt+LGr8Yj1BWfJILf6ilrw gt////uv84BE1yyfgXcK78hUijRqeL/wcftGpm9p5RRtNXncEpKJS7d7uKIrxkiUgf 1/h55lyOSWMI82PhCETmed+C+eOiUeNIUpPBnEKU= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/99277] C++2a synchronisation is inefficient in GCC 11 Date: Mon, 08 May 2023 16:39:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: ABI X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: target_milestone Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99277 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|12.4 |12.0 --- Comment #14 from Jonathan Wakely --- For the record ... (In reply to Thiago Macieira from comment #0) > Here's a summary of the findings: >=20 > 1) everything is inline No change here yet, it's intentional that nothing has been added to the lib= rary for now. > 2) futex code is still behind a lot of code calling into std::_Hash_bytes That changed with r12-10-gb52aef3a8cbcc8 > 3) other int-sized (incl. enums) atomics don't use futex So did that. > 4) std::latch and std::counting_semaphore defaults preclude from using > futex on Linux And that. > 5) std::barrier implementation also uses a type that futex(2) can't hand= le barrier still uses a 1-byte enum for the atomic waits.=