[libc++] Always query the compiler to find whether a type is always lockfree

In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Fr

[libc++] Always query the compiler to find whether a type is always lockfree

In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.

After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).

However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.

This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.

Fixes #57440

Differential Revision: https://reviews.llvm.org/D133377

(cherry picked from commit f1a601fe88f99d52ca80617266897b217bcd4d64)

show more ...

[libc++] Undeprecate ATOMIC_FLAG_INIT (LWG3659)

According to @aaron.ballman this was marked Tentatively Ready as of 2022-07-07.
D129362 implemented the C counterpart.

Reviewed By: ldionne, #libc, M

[libc++] Undeprecate ATOMIC_FLAG_INIT (LWG3659)

According to @aaron.ballman this was marked Tentatively Ready as of 2022-07-07.
D129362 implemented the C counterpart.

Reviewed By: ldionne, #libc, Mordante

Differential Revision: https://reviews.llvm.org/D129380

show more ...

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spie

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits, miyuki

Differential Revision: https://reviews.llvm.org/D129051

show more ...

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.

Differential Revision: https://reviews.llvm.org/D128661

show more ...

[libcxx] Switch __cxx_contention_t to int32_t on 32 bit AIX

I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.

Previou

[libcxx] Switch __cxx_contention_t to int32_t on 32 bit AIX

I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.

Previously, this used int32_t for this type on linux, but int64_t
on all other platforms. This was added in D68480 /
54fa9ecd3088508b05b0c5b5cb52da8a3c188655, but I don't really see
any discussion around this detail there.

Switching this to 32 bit on 32 bit AIX silences these libcxx build
warnings:

```
In file included from /scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/libcxx/src/atomic.cpp:12:
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1005:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:948:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1000:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1022:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_sub(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
4 warnings generated.
```

Differential Revision: https://reviews.llvm.org/D124519

show more ...

[libc++][P0943] Add stdatomic.h header.

* https://wg21.link/P0943
* https://eel.is/c++draft/stdatomic.h.syn

This is a re-application of 5d1c1a24, which was reverted in 987c7f407
because it broke th

[libc++][P0943] Add stdatomic.h header.

* https://wg21.link/P0943
* https://eel.is/c++draft/stdatomic.h.syn

This is a re-application of 5d1c1a24, which was reverted in 987c7f407
because it broke the LLDB build.

Co-authored-by: Marek Kurdej <[email protected]>

Differential Revision: https://reviews.llvm.org/D97044

show more ...

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

Differential Revision: https://reviews.llvm.org/D122506

show more ...

[libc++] Granularize chrono includes

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D120141

[libc++] Remove a few unneeded _LIBCPP_CXX03_LANG ifdefs

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D119896

[libc++] Revert <stdatomic.h> changes

This reverts commits a30a7948d and 5d1c1a243, which broke the LLDB
data formatters tests because they build with modules in C++11 mode.

Differential Revision:

[libc++] Revert <stdatomic.h> changes

This reverts commits a30a7948d and 5d1c1a243, which broke the LLDB
data formatters tests because they build with modules in C++11 mode.

Differential Revision: https://reviews.llvm.org/D97044

show more ...

[libc++] [C++2b] [P0943] Add stdatomic.h header.

* https://wg21.link/P0943
* https://eel.is/c++draft/stdatomic.h.syn

Differential Revision: https://reviews.llvm.org/D97044

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D1188

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

Differential Revision: https://reviews.llvm.org/D118800

show more ...

Omit atomic_{,un}signed_lock_free if unsupported

On targets that have limited atomic support, e.g. ones that define
ATOMIC_*_LOCK_FREE to '1' ("sometimes lock free"), we would end up
referencing yet

Omit atomic_{,un}signed_lock_free if unsupported

On targets that have limited atomic support, e.g. ones that define
ATOMIC_*_LOCK_FREE to '1' ("sometimes lock free"), we would end up
referencing yet-undefined __libcpp_{,un}signed_lock_free.

This commit adds a guard to prevent these references for such
targets.

Differential Revision: https://reviews.llvm.org/D118391

show more ...

[libc++] Split a few utilities out of __threading_support

This change is the basis for a further refactoring where I'm going to
split up the various implementations we have in __threading_support to

[libc++] Split a few utilities out of __threading_support

This change is the basis for a further refactoring where I'm going to
split up the various implementations we have in __threading_support to
make that code easier to understand.

Note that I had to make __convert_to_timespec a template to break
circular dependencies. Concretely, we never seem to use it with anything
other than ::timespec, but I am wary of hardcoding that assumption as
part of this change, since I suspect there's a reason for going through
these hoops in the first place.

Differential Revision: https://reviews.llvm.org/D116944

show more ...

[libcxx] Add deprecation notices to macros deprecated in P0883R2

When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc

[libcxx] Add deprecation notices to macros deprecated in P0883R2

When P0883R2 was initially implemented in D103769 #pragma clang deprecated didn't exist yet.
We also forgot to cleanup usages in libc++ itself.

This takes care of both.

Differential Revision: https://reviews.llvm.org/D115995

show more ...

[libc++] Remove _LIBCPP_DEFAULT

clang has `= default` as an extension in c++03, so just use it.

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits

Differential Revision: https://revie

[libc++] Remove _LIBCPP_DEFAULT

clang has `= default` as an extension in c++03, so just use it.

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D115275

show more ...

[libc++] Enable <atomic> when threads are disabled

std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not availabl

[libc++] Enable <atomic> when threads are disabled

std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.

This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
threads are disabled.
- Runs the <atomic> tests when threads are disabled.

rdar://77873569

Differential Revision: https://reviews.llvm.org/D114109

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libc++] Refactor tests for trivially copyable atomics

- Replace irrelevant synopsis by a comment
- Use a .verify.cpp test instead of .compile.fail.cpp
- Remove unnecessary includes in one of the te

[libc++] Refactor tests for trivially copyable atomics

- Replace irrelevant synopsis by a comment
- Use a .verify.cpp test instead of .compile.fail.cpp
- Remove unnecessary includes in one of the tests (was a copy-paste error)

Differential Revision: https://reviews.llvm.org/D114094

show more ...

[libc++] Update atomic synopsis and tests.

While looking at LWG-2988 and P0558 it seems the issues were already
implemented, but the synopsis wasn't updated. Some of the tests didn't
validate the `n

[libc++] Update atomic synopsis and tests.

While looking at LWG-2988 and P0558 it seems the issues were already
implemented, but the synopsis wasn't updated. Some of the tests didn't
validate the `noexcept` status. A few tests were missing completely:
- `atomic_wait_explicit`
- `atomic_notify_one`
- `atomic_notify_all`

Mark P0558 as complete, didn't investigate which version of libc++ first
includes this. It seems the paper has been retroactively applied. I
couldn't find whether this is correct, but looking at cppreference it
seems intended.

Completes
- LWG-2988 Clause 32 cleanup missed one typename
- P0558 Resolving atomic<T> named base class inconsistencies

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D103765

show more ...

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

Differential Revision: https://reviews.llvm.org/D111265

show more ...

[libc++] Improve atomic_fetch_(add|sub).*.

While looking at the review comments in D103765 there was an oddity in
the tests for the following functions:
- atomic_fetch_add
- atomic_fetch_add_explici

[libc++] Improve atomic_fetch_(add|sub).*.

While looking at the review comments in D103765 there was an oddity in
the tests for the following functions:
- atomic_fetch_add
- atomic_fetch_add_explicit
- atomic_fetch_sub
- atomic_fetch_sub_explicit

Libc++ allows usage of
`atomic_fetch_add<int>(atomic<int*>*, atomic<int*>::difference_type);`
MSVC and GCC reject this code: https://godbolt.org/z/9d8WzohbE

This makes the atomic `fetch(add|sub).*` Standard conforming and removes the non-conforming extensions.

Fixes PR47908

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D103983

show more ...

[libc++] Remove some workarounds for unsupported GCC and Clang versions

There is a lot more we can do, in particular in <type_traits>, but this
removes some workarounds that were gated on checking a

[libc++] Remove some workarounds for unsupported GCC and Clang versions

There is a lot more we can do, in particular in <type_traits>, but this
removes some workarounds that were gated on checking a specific compiler
version.

Differential Revision: https://reviews.llvm.org/D108923

show more ...

[libcxx] Implement P0883R2 ("Fixing Atomic Initialization")

Reviewed By: Quuxplusone

Differential Revision: https://reviews.llvm.org/D103769

[libcxx][atomic] Fix failure mapping in compare_exchange_{strong,weak}.

https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_ord

[libcxx][atomic] Fix failure mapping in compare_exchange_{strong,weak}.

https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`.

This failure mapping is only handled for `_LIBCPP_HAS_GCC_ATOMIC_IMP`. We are seeing bad code generation for `compare_exchange_strong(cmp, 1, std::memory_order_acq_rel)` when using libc++ in place of libstdc++: https://godbolt.org/z/v3onrrq4G.

This was caught by tsan tests after D99434, `[TSAN] Honor failure memory orders in AtomicCAS`, but appears to be an issue in non-tsan code.

Reviewed By: ldionne, dvyukov

Differential Revision: https://reviews.llvm.org/D103846

show more ...