public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/108235] FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link Date: Fri, 06 Jan 2023 21:21:05 +0000 [thread overview] Message-ID: <bug-108235-4-GyVqnAzExQ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108235-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108235 --- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>: https://gcc.gnu.org/g:61da01772a3dff61cf23ba2ffba33bccb68d1063 commit r13-5052-g61da01772a3dff61cf23ba2ffba33bccb68d1063 Author: Jonathan Wakely <jwakely@redhat.com> Date: Fri Jan 6 18:39:14 2023 +0000 libstdc++: Refactor time_zone::_Impl::rules_counter [PR108235] Abstract the atomic counter used to synchronize access to time_zone infos behind a Lockable class API, and use atomic_signed_lock_free instead of atomic<int_least32_t>, as that should be the most efficient type. (For futex-supporting targets it makes no difference, but might benefit other targets in future.) The new API allows the calling code to be simpler, without needing to repeat the same error prone preprocessor conditions in multiple places. It also allows using template metaprogramming to decide whether to use the atomic or a mutex, which gives us more flexibility than only using preprocessor conditions. That allows us to choose the mutex implementation for targets such as hppa-hp-hpux11.11 where 32-bit atomics are not lock-free and so would introduce an unwanted dependency on libatomic. libstdc++-v3/ChangeLog: PR libstdc++/108235 * src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): New class template and partial specialization for synchronizing access to time_zone::_Impl::infos. (time_zone::_M_get_sys_info, reload_tzdb): Adjust uses of rules_counter.
next prev parent reply other threads:[~2023-01-06 21:21 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-27 14:43 [Bug libstdc++/108235] New: " danglin at gcc dot gnu.org 2022-12-29 15:55 ` [Bug libstdc++/108235] " danglin at gcc dot gnu.org 2022-12-29 16:12 ` danglin at gcc dot gnu.org 2022-12-29 20:27 ` danglin at gcc dot gnu.org 2022-12-30 17:08 ` redi at gcc dot gnu.org 2022-12-30 17:08 ` redi at gcc dot gnu.org 2023-01-02 17:59 ` danglin at gcc dot gnu.org 2023-01-02 18:17 ` redi at gcc dot gnu.org 2023-01-05 0:51 ` cvs-commit at gcc dot gnu.org 2023-01-05 0:54 ` redi at gcc dot gnu.org 2023-01-05 2:11 ` dave.anglin at bell dot net 2023-01-06 15:01 ` danglin at gcc dot gnu.org 2023-01-06 15:06 ` danglin at gcc dot gnu.org 2023-01-06 16:51 ` redi at gcc dot gnu.org 2023-01-06 21:21 ` cvs-commit at gcc dot gnu.org [this message] 2023-01-06 21:22 ` redi at gcc dot gnu.org 2023-01-08 20:47 ` danglin at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108235-4-GyVqnAzExQ@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).