<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in atomic</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>bbd871e2baad2e74dbde202823b3439d2a96d3f8 - [libc++] Don&apos;t implement &lt;stdatomic.h&gt; before C++23 (#123130)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#bbd871e2baad2e74dbde202823b3439d2a96d3f8</link>
        <description>[libc++] Don&apos;t implement &lt;stdatomic.h&gt; before C++23 (#123130)https://github.com/llvm/llvm-project/pull/95498 implemented a libc++extension where &lt;stdatomic.h&gt; would forward to &lt;atomic&gt; even beforeC++23. Unfortunately, this was found to be a breaking change (withfairly widespread impact) since that changes whether _Atomic(T) is a Cstyle atomic or std::atomic&lt;T&gt;. In principle, this can even be an ABIbreak.We generally don&apos;t implement extensions in libc++ because they cause somany problems, and that extension had been accepted because it wasdeemed pretty small and only a quality of life improvement. Since it haswidespread impact on valid C++20 (and before) code, this patch removesthe extension before we ship it in any public release.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Fri, 17 Jan 2025 19:22:40 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>b9a2658a3e8bd13b0f9e7a8a440832a95b377216 - [libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#b9a2658a3e8bd13b0f9e7a8a440832a95b377216</link>
        <description>[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)This patch implements the forwarding to frozen C++03 headers asdiscussed inhttps://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In theRFC, we initially proposed selecting the right headers from the Clangdriver, however consensus seemed to steer towards handling this in thelibrary itself. This patch implements that direction.At a high level, the changes basically amount to making each publicheader look like this:```// inside &lt;vector&gt;#ifdef _LIBCPP_CXX03_LANG#  include &lt;__cxx03/vector&gt;#else  // normal &lt;vector&gt; content#endif```In most cases, public headers are simple umbrella headers so there isn&apos;tmuch code in the #else branch. In other cases, the #else branch containsthe actual implementation of the header.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Sat, 21 Dec 2024 12:01:48 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>c166a9c713ec86b86f1f178a5133bc128fd0a610 - [libc++] Add #if 0 block to all the top-level headers (#119234)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#c166a9c713ec86b86f1f178a5133bc128fd0a610</link>
        <description>[libc++] Add #if 0 block to all the top-level headers (#119234)Including The frozen C++03 headers results in a lot of formattingchanges in the main headers, so this splits these changes into aseparate commit instead.This is part ofhttps://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Tue, 10 Dec 2024 15:02:12 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>0e34f3f4968d8d32a64e26777541f939deb2274c - [libc++] Extract a clean base support API for std::atomic (#118129)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#0e34f3f4968d8d32a64e26777541f939deb2274c</link>
        <description>[libc++] Extract a clean base support API for std::atomic (#118129)This patch documents the underlying API for implementing atomics on aplatform.This doesn&apos;t change the operations that std::atomic is based on, but itreorganizes the C11 / GCC implementation split to make it clearer what&apos;sthe base support layer and what&apos;s not.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Mon, 09 Dec 2024 14:14:17 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>3a63407686313f46f9abc664fd10b01f4359ee27 - [libc++] Make __atomic_base into an implementation detail of std::atomic (#115764)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#3a63407686313f46f9abc664fd10b01f4359ee27</link>
        <description>[libc++] Make __atomic_base into an implementation detail of std::atomic (#115764)The __atomic_base base class is only useful to conditionalize theoperations we provide inside std::atomic. It shouldn&apos;t be used directlyfrom other places in the library which can use std::atomic directlyinstead.Since we&apos;ve granularized our includes, using std::atomic directly shouldnot make much of a difference compile-time wise.This patch starts using std::atomic directly from other classes likestd::barrier and std::latch. Changing this shouldn&apos;t be an ABI breaksince both classes have the same size and layout.The benefits of this patch are isolating other parts of the code basefrom implementation details of std::atomic and simplifying the mentalmodel for std::atomic&apos;s layers of implementation by making it clear that__atomic_base is only an implementation detail of std::atomic.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Tue, 19 Nov 2024 23:35:14 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>e99c4906e44ae3f921fa05356909d006cda8d954 - [libc++] Granularize &lt;cstddef&gt; includes (#108696)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#e99c4906e44ae3f921fa05356909d006cda8d954</link>
        <description>[libc++] Granularize &lt;cstddef&gt; includes (#108696)

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Thu, 31 Oct 2024 01:20:10 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>ba87515fea90b5d55836a8e3be63a7e683ce299d - [libc++][RFC] Always define internal feature test macros (#89178)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#ba87515fea90b5d55836a8e3be63a7e683ce299d</link>
        <description>[libc++][RFC] Always define internal feature test macros (#89178)Currently, the library-internal feature test macros are only defined ifthe feature is not available, and always have the prefix`_LIBCPP_HAS_NO_`. This patch changes that, so that they are alwaysdefined and have the prefix `_LIBCPP_HAS_` instead. This changes thecanonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which meansthat using an undefined macro (e.g. due to a missing include) isdiagnosed now. While this is rather unlikely currently, a similar changein `&lt;__configuration/availability.h&gt;` caught a few bugs. This alsoimproves readability, since it removes the double-negation of `#ifndef_LIBCPP_HAS_NO_FEATURE`.The current patch only touches the macros defined in `&lt;__config&gt;`. Ifpeople are happy with this approach, I&apos;ll make a follow-up PR to alsochange the macros defined in `&lt;__config_site&gt;`.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Sat, 12 Oct 2024 07:49:52 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>2d26fc8c6c5015b77dc725695c1d957f412e4141 - [libc++] Enable C++ stdatomic.h for all C++ versions (#95498)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#2d26fc8c6c5015b77dc725695c1d957f412e4141</link>
        <description>[libc++] Enable C++ stdatomic.h for all C++ versions (#95498)This extension is motivated by Android&apos;s use of libc++, where&lt;stdatomic.h&gt; has redirected to &lt;atomic&gt; for many years, long before itwas standardized in C++23.When libc++&apos;s stdatomic.h is included in C translation units, delegateto the next stdatomic.h, which could come from Clang or libc.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Thu, 19 Sep 2024 13:43:54 +0000</pubDate>
        <dc:creator>Ryan Prichard &lt;rprichard@google.com&gt;</dc:creator>
    </item>
<item>
        <title>bf1666fb0bc19ffa18072e2727e4611c293a9aee - [libc++] Drop support for the C++20 Synchronization Library before C++20 (#82008)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#bf1666fb0bc19ffa18072e2727e4611c293a9aee</link>
        <description>[libc++] Drop support for the C++20 Synchronization Library before C++20 (#82008)When we initially implemented the C++20 synchronization library, wereluctantly accepted for the implementation to be backported to C++03upon request from the person who provided the patch. This was when wewere only starting to have experience with the issues this can create,so we flinched. Nowadays, we have a much stricter stance about notbackporting features to previous standards.We have recently started fixing several bugs (and near bugs) in ourimplementation of the synchronization library. A recurring theme duringthese reviews has been how difficult to understand the current code is,and upon inspection it becomes clear that being able to use a few recentC++ features (in particular lambdas) would help a great deal. The codewould still be pretty intricate, but it would be a lot easier to reasonabout the flow of callbacks through things like__thread_poll_with_backoff.As a result, this patch drops support for the synchronization librarybefore C++20. This makes us more strictly conforming and opens the doorto major simplifications, in particular around atomic_wait which wassupported all the way to C++03.This change will probably have some impact on downstream users, howeversince the C++20 synchronization library was added only in LLVM 10 (~3years ago) and it&apos;s quite a niche feature, the set of people trying touse this part of the library before C++20 should be reasonably small.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Wed, 31 Jul 2024 21:53:09 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>dfddc0c4843baaf9605aeb1c4f82eac185e90265 - [libc++] Include the rest of the detail headers by version in the umbrella headers (#96032)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#dfddc0c4843baaf9605aeb1c4f82eac185e90265</link>
        <description>[libc++] Include the rest of the detail headers by version in the umbrella headers (#96032)This is a follow-up to #83740.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Thu, 18 Jul 2024 08:59:58 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>42ba740afffa16f991be6aa36626bd872d41ebc0 - [libc++] Implement C++20 atomic_ref (#76647)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#42ba740afffa16f991be6aa36626bd872d41ebc0</link>
        <description>[libc++] Implement C++20 atomic_ref (#76647)Implement the std::atomic_ref class template by reusing atomic_base_impl.Based on the work from https://reviews.llvm.org/D72240

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Tue, 21 May 2024 22:54:08 +0000</pubDate>
        <dc:creator>Damien L-G &lt;dalg24@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>40081a45a14f7aa6249fa034d961549c0b1762a0 - [libc++] Fix diagnostic for &lt;stdatomic.h&gt; before C++23 (#83351)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#40081a45a14f7aa6249fa034d961549c0b1762a0</link>
        <description>[libc++] Fix diagnostic for &lt;stdatomic.h&gt; before C++23 (#83351)We normally try to issue a reasonable diagnostic when mixing&lt;stdatomic.h&gt; and &lt;atomic&gt; before C++23. However, after granularizingthe &lt;atomic&gt; header, the check and the #error message was moved to*after* the point where mixing both causes problems. When mixing bothheaders, we would hence get the diagnostic burried under a pile ofprevious diagnostics in e.g. __atomic/kill_dependency.h.This patch moves the check earlier to restore the intended behavior. Italso switches from `#ifdef kill_dependency` to an explicit check of theinclusion of the header and the Standard version, which seems to be morereliable than checking whether a macro is defined.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Mon, 04 Mar 2024 23:24:51 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>37dca605c9bd41732da010ee97ed15ad9585a37d - [libc++] Clean up includes of &lt;__assert&gt; (#80091)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#37dca605c9bd41732da010ee97ed15ad9585a37d</link>
        <description>[libc++] Clean up includes of &lt;__assert&gt; (#80091)Originally, we used __libcpp_verbose_abort to handle assertion failures.That function was declared from all public headers. Since we don&apos;t usethat mechanism anymore, we don&apos;t need to declare __libcpp_verbose_abortfrom all public headers, and we can clean up a lot of unnecessaryincludes.This patch also moves the definition of the various assertion categoriesto the &lt;__assert&gt; header, since we now rely on regular IWYU for theseassertion macros.rdar://105510916

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Thu, 29 Feb 2024 15:12:22 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>153003416696c2464d296594dac5a36a5a60bac5 - [libc++] Remove unnecessary includes from &lt;atomic&gt; (#82880)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#153003416696c2464d296594dac5a36a5a60bac5</link>
        <description>[libc++] Remove unnecessary includes from &lt;atomic&gt; (#82880)This reduces the include time of `&lt;atomic&gt;` from 135ms to 88ms.

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Wed, 28 Feb 2024 20:14:35 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>6f0c52e56fb7f237ed8071573ce8a2021b4c7289 - [libc++] Refactor atomic_{unsigned,signed}_lock_free (#73041)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#6f0c52e56fb7f237ed8071573ce8a2021b4c7289</link>
        <description>[libc++] Refactor atomic_{unsigned,signed}_lock_free (#73041)Their definition was a bit roundabout and it was actually wrong sinceatomic_unsigned_lock_free would be a signed type whenever__cxx_contention_t is lock free, which is most of the time.Fixes #72968

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Wed, 22 Nov 2023 19:54:40 +0000</pubDate>
        <dc:creator>Louis Dionne &lt;ldionne.2@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>de7fbfeef5984ed3dc178957fbfaf4b1bb95fa94 - [libc++] Floating Point Atomic (#67799)</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#de7fbfeef5984ed3dc178957fbfaf4b1bb95fa94</link>
        <description>[libc++] Floating Point Atomic (#67799)- implement P0020R6 Floating Point AtomicDifferential Revision: https://reviews.llvm.org/D153981

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Wed, 22 Nov 2023 11:48:49 +0000</pubDate>
        <dc:creator>Hui &lt;hui.xie0621@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>70617a1a2389a1abe6151d52dc749fb5f7755439 - [libc++] Granularize &lt;atomic&gt; includes</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#70617a1a2389a1abe6151d52dc749fb5f7755439</link>
        <description>[libc++] Granularize &lt;atomic&gt; includesReviewed By: ldionne, Mordante, #libcSpies: arichardson, libcxx-commitsDifferential Revision: https://reviews.llvm.org/D144255

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Tue, 31 Jan 2023 18:23:30 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>46db8d822ecdf36a714de5e1acf187736a3af5d1 - [libc++] Granularize &lt;atomic&gt;</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#46db8d822ecdf36a714de5e1acf187736a3af5d1</link>
        <description>[libc++] Granularize &lt;atomic&gt;Reviewed By: Mordante, #libcSpies: arichardson, libcxx-commits, krytarowskiDifferential Revision: https://reviews.llvm.org/D142972

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Sat, 14 Jan 2023 01:53:52 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>4f15267d3dd797a15901fe9352f0d5fa121b9095 - [libc++][NFC] Replace _LIBCPP_STD_VER &gt; x with _LIBCPP_STD_VER &gt;= x</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#4f15267d3dd797a15901fe9352f0d5fa121b9095</link>
        <description>[libc++][NFC] Replace _LIBCPP_STD_VER &gt; x with _LIBCPP_STD_VER &gt;= xThis change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER &gt;=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed.Reviewed By: ldionne, var-const, #libcSpies: jloser, libcxx-commits, arichardson, arphaman, wenleiDifferential Revision: https://reviews.llvm.org/D143962

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Mon, 13 Feb 2023 23:56:09 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
<item>
        <title>dc21ce44047a634ee9072157b6dc40926f02458a - [libc++] Remove &lt;type_traits&gt; includes from &lt;atomic&gt; and &lt;ratio&gt;</title>
        <link>http://src.rcs.uwaterloo.ca:8080/source/history/llvm-project/libcxx/include/atomic#dc21ce44047a634ee9072157b6dc40926f02458a</link>
        <description>[libc++] Remove &lt;type_traits&gt; includes from &lt;atomic&gt; and &lt;ratio&gt;Reviewed By: Mordante, #libcSpies: libcxx-commitsDifferential Revision: https://reviews.llvm.org/D141799

            List of files:
            /llvm-project/libcxx/include/atomic</description>
        <pubDate>Sun, 15 Jan 2023 18:53:49 +0000</pubDate>
        <dc:creator>Nikolas Klauser &lt;nikolasklauser@berlin.de&gt;</dc:creator>
    </item>
</channel>
</rss>
