[libc++][NFC] Replace uses of NULL by nullptr (#108847)

Closes #108741

[libc++] Mark a few functions in the dylib as noexcept (#94098)

This avoids generating landing pads in some of the `atomic` functions
that will never be used, since these functions never throw exce

[libc++] Mark a few functions in the dylib as noexcept (#94098)

This avoids generating landing pads in some of the `atomic` functions
that will never be used, since these functions never throw exceptions.

show more ...

[libc++] Fix `std::atomic::wait` ulock wait UL_COMPARE_AND_WAIT64 (#92783)

in `atomic::wait`, when we call the platform wait ulock_wait , we are
using UL_COMPARE_AND_WAIT. But we should use UL_COMP

[libc++] Fix `std::atomic::wait` ulock wait UL_COMPARE_AND_WAIT64 (#92783)

in `atomic::wait`, when we call the platform wait ulock_wait , we are
using UL_COMPARE_AND_WAIT. But we should use UL_COMPARE_AND_WAIT64
instead as the address we are waiting for is a 64 bit integer.

fixes https://github.com/llvm/llvm-project/issues/85107

It is rather hard to test directly because in `atomic::wait`, before
calling into the platform wait, our c++ code has some poll logic which
checks the value not changing. Thus in this patch, the test is using the
internal function.

show more ...

[libcxx][libcxxabi] Fix build for OpenBSD (#92186)

- No indirect syscalls on OpenBSD. Instead there is a `futex` function
which issues a direct syscall.

- Monotonic clock is available despite th

[libcxx][libcxxabi] Fix build for OpenBSD (#92186)

- No indirect syscalls on OpenBSD. Instead there is a `futex` function
which issues a direct syscall.

- Monotonic clock is available despite the full POSIX suite of timers
not being available in its entirety.

See https://lists.boost.org/boost-bugs/2015/07/41690.php and
https://github.com/boostorg/log/commit/c98b1f459add14d5ce3e9e63e2469064601d7f71
for a description of an analogous problem and fix for Boost.

show more ...

[libc++] Refactor the predicate taking variant of `__cxx_atomic_wait` (#80596)

This is a follow-up PR to
<https://github.com/llvm/llvm-project/pull/79265>. It aims to be a
gentle refactoring of th

[libc++] Refactor the predicate taking variant of `__cxx_atomic_wait` (#80596)

This is a follow-up PR to
<https://github.com/llvm/llvm-project/pull/79265>. It aims to be a
gentle refactoring of the `__cxx_atomic_wait` function that takes a
predicate.

The key idea here is that this function's signature is changed to look
like this (`std::function` used just for clarity):

```c++
__cxx_atomic_wait_fn(Atp*, std::function<bool(Tp &)> poll, memory_order __order);
```

...where `Tp` is the corresponding `value_type` to the atomic variable
type `Atp`. The function's semantics are similar to `atomic`s `.wait()`,
but instead of having a hardcoded predicate (is the loaded value unequal
to `old`?) the predicate is specified explicitly.

The `poll` function may change its argument, and it is very important
that if it returns `false`, it leaves its current understanding of the
atomic's value in the argument. Internally, `__cxx_atomic_wait_fn`
dispatches to two waiting mechanisms, depending on the type of the
atomic variable:

1. If the atomic variable can be waited on directly (for example,
Linux's futex mechanism only supports waiting on 32 bit long variables),
the value of the atomic variable (which `poll` made its decision on) is
then given to the underlying system wait function (e.g. futex).
2. If the atomic variable can not be waited on directly, there is a
global pool of atomics that are used for this task. The ["eventcount"
pattern](<https://gist.github.com/mratsim/04a29bdd98d6295acda4d0677c4d0041>)
is employed to make this possible.

The eventcount pattern needs a "monitor" variable which is read before
the condition is checked another time. libcxx has the
`__libcpp_atomic_monitor` function for this. However, this function only
has to be called in case "2", i.e. when the eventcount is actually used.
In case "1", the futex is used directly, so the monitor must be the
value of the atomic variable that the `poll` function made its decision
on to continue blocking. Previously, `__libcpp_atomic_monitor` was
_also_ used in case "1". This was the source of the ABA style bug that
PR#79265 fixed.

However, the solution in PR#79265 has some disadvantages:

- It exposes internals such as `cxx_contention_t` or the fact that
`__libcpp_thread_poll_with_backoff` needs two functions to higher level
constructs such as `semaphore`.
- It doesn't prevent consumers calling `__cxx_atomic_wait` in an error
prone way, i.e. by providing to it a predicate that doesn't take an
argument. This makes ABA style issues more likely to appear.

Now, `__cxx_atomic_wait_fn` takes just _one_ function, which is then
transformed into the `poll` and `backoff` callables needed by
`__libcpp_thread_poll_with_backoff`.

Aside from the `__cxx_atomic_wait` changes, the only other change is the
weakening of the initial atomic load of `semaphore`'s `try_acquire` into
`memory_order_relaxed` and the CAS inside the loop is changed from
`strong` to `weak`. Both weakenings should be fine, since the CAS is
called in a loop, and the "acquire" semantics of `try_acquire` come from
the CAS, not from the initial load.

show more ...

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmar

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all

show more ...

[libc++] Handle threads-related .cpp files like we do all other source files (#71100)

Source files in libc++ are added to the CMake targets only if they are
required by the configuration. We do thi

[libc++] Handle threads-related .cpp files like we do all other source files (#71100)

Source files in libc++ are added to the CMake targets only if they are
required by the configuration. We do this pretty consistently for all
configurations like no-filesystem, no-random-device, etc. but we didn't
do it for no-threads. This patch makes this consistent for no-threads,
which is helpful in reducing the amount of work required to port libc++
to some platforms without threads.

Indeed, with the previous approach, several threads-related source files
would end up including headers that might fail to compile properly on
some platforms. This issue is sidestepped entirely by making the
approach for no-threads consistent with the other configurations.

show more ...

[libc++] Fix warnings when compiling libc++ for Windows with clang-cl /W4

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

[libc++] Make sure we use __ulock on Apple platforms

We forgot to include the header, which means that _LIBCPP_USE_ULOCK was
always undefined and we'd always use the fallback. Note that this doesn't

[libc++] Make sure we use __ulock on Apple platforms

We forgot to include the header, which means that _LIBCPP_USE_ULOCK was
always undefined and we'd always use the fallback. Note that this doesn't
seem to fix https://github.com/llvm/llvm-project/issues/63737.

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

show more ...

[libc++][NFC] Granularise <thread> header

- This was to make implementing jthread easier and requested in https://reviews.llvm.org/D151559

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

[libc++] [FreeBSD] correct 64-bit test

Using __SIZEOF_LONG__ == 8 rather than __LP64__ is needed so we use umtx
on CHERI. I accidentally landed an older diff.

Fixes: 17ecbb3ea6ff0ae716dd524c0e2bf7

[libc++] [FreeBSD] correct 64-bit test

Using __SIZEOF_LONG__ == 8 rather than __LP64__ is needed so we use umtx
on CHERI. I accidentally landed an older diff.

Fixes: 17ecbb3ea6ff0ae716dd524c0e2bf75a4815c95b

show more ...

[libc++] [FreeBSD] only use _umtx_op(2) on 64bit arches

Only 64bit architectures can be supported this way, because libcxx
defines __cxx_contention_t to be int64_t for FreeBSD, and 32bit
arches do n

[libc++] [FreeBSD] only use _umtx_op(2) on 64bit arches

Only 64bit architectures can be supported this way, because libcxx
defines __cxx_contention_t to be int64_t for FreeBSD, and 32bit
arches do not have a kind of UMTX_OP_WAIT_INT64_PRIVATE operation.

Fixes: 83387dbc18e7998f87aa4a2d35320bcb2ed5c392

Reviewed by: arichardson, ldionne, emaste, Mordante
Differential Revision: https://reviews.llvm.org/D142422

show more ...

[libc++] add FreeBSD atomic wait support

Reviewed By: philnik

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

[libc++] Extend check for non-ASCII characters to src/, test/ and benchmarks/

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

[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 ...

[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++] Fix libcxx build on 32bit architectures with 64bit time_t defaults e.g. riscv32

Patch by Khem Raj.

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

[libc++] NFC: Remove unused <iostream> include in atomic.cpp

[libc++] Implementation of C++20's P1135R6 for libcxx

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

Still working on the basic design of <atomic>. I'm working towards a system by which the compiler only needs to define the strongest intrinsics it can. Weaker atomics in the library automatically t

Still working on the basic design of <atomic>. I'm working towards a system by which the compiler only needs to define the strongest intrinsics it can. Weaker atomics in the library automatically try stronger and stronger variants, picking the weakest compiler intrinsic available. If no compiler intrinsics are available for a given operation, the library locks a mutex and does the job. Better documentation to follow...

llvm-svn: 115538

show more ...