[libcxx] Support for using timespec_get (#117362)

clock_gettime is a POSIX API that may not be available on platforms like
baremetal; timespec_get is the C11 equivalent. This change adds support
f

[libcxx] Support for using timespec_get (#117362)

clock_gettime is a POSIX API that may not be available on platforms like
baremetal; timespec_get is the C11 equivalent. This change adds support
for using timespec_get instead of clock_gettime to improve compatibility
with non-POSIX platforms. For now, this is only enabled with LLVM libc
which implemented timespec_get in #116102, but in the future this can be
expanded to other platforms.

Related to #84879.

show more ...

[libc++] Avoid including <string> in <mutex> (#116254)

[libc++] Make variables in templates inline (#115785)

The variables are all `constexpr`, which implies `inline`. Since they
aren't `constexpr` in C++03 they're also not `inline` there. Because of

[libc++] Make variables in templates inline (#115785)

The variables are all `constexpr`, which implies `inline`. Since they
aren't `constexpr` in C++03 they're also not `inline` there. Because of
that we define them out-of-line currently. Instead we can use the C++17
extension of `inline` variables, which results in the same weak
definitions of the variables but without having all the boilerplate.

show more ...

[libc++] Refactor the configuration macros to being always defined (#112094)

This is a follow-up to #89178. This updates the `<__config_site>`
macros.

[libcxx] Set `_LIBCPP_HAS_CLOCK_GETTIME` for GPU targets (#99243)

Summary:
I am attempting to get the GPU to build and support libc++. One issue
I've encountered is that it will look for `timeval`

[libcxx] Set `_LIBCPP_HAS_CLOCK_GETTIME` for GPU targets (#99243)

Summary:
I am attempting to get the GPU to build and support libc++. One issue
I've encountered is that it will look for `timeval` unless this macro is
set. We can support `CLOCK_MONOTONIC` on the GPU fairly easily as we
have access to a fixed-frequency clock via `__builtin_readsteadycounter`
intrinsics with a known frequency. This also requires `CLOCK_REALTIME`
which we can't support, but provide anyway from the GPU `libc` to make
this happy. It will return an error so at least that will be obvious.

I may need a more consistent configuration for this in the future, maybe
I should put a common macro in a different common header that's just
`__GPU__`? I don't know where I would put such a thing however.

show more ...

[libcxx] Add cast to avoid pointer casting warning on Windows (#92738)

This avoids the following build time warning, when building with the
latest nightly Clang:

warning: cast from 'FARPROC' (ak

[libcxx] Add cast to avoid pointer casting warning on Windows (#92738)

This avoids the following build time warning, when building with the
latest nightly Clang:

warning: cast from 'FARPROC' (aka 'int (*)() __attribute__((stdcall))')
to
'GetSystemTimeAsFileTimePtr' (aka 'void (*)(_FILETIME *)
__attribute__((stdcall))')
converts to incompatible function type [-Wcast-function-type-mismatch]

This warning seems to have appeared since Clang commit
999d4f840777bf8de26d45947192aa0728edc0fb, which restructured.

The GetProcAddress function returns a `FARPROC` type, which is `int
(WINAPI *)()`. Directly casting this to another function pointer type
triggers this warning, but casting to a `void*` inbetween avoids this
issue. (On Unix-like platforms, dlsym returns a `void*`, which doesn't
exhibit this casting problem.)

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++] 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++] Replace uses of _VSTD:: by std:: (#74331)

As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm

[libc++] Replace uses of _VSTD:: by std:: (#74331)

As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.

show more ...

[libc++] Fix GNU/Hurd build

GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete.

Reviewed By: #libc, Mordante

Differential Revisio

[libc++] Fix GNU/Hurd build

GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete.

Reviewed By: #libc, Mordante

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

show more ...

[libc++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylib

Since we build the dylib with C++20, there's no need to use conditional
macros anymore.

Differential Revision: https://reviews.

[libc++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylib

Since we build the dylib with C++20, there's no need to use conditional
macros anymore.

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

show more ...

[libc++] Fix clock selection in chrono.cpp and filesystem_clock.cpp

This patch partly reverts the change that was made in 5f1ba3a502
regarding the clock selection on Apple platforms. It turns out th

[libc++] Fix clock selection in chrono.cpp and filesystem_clock.cpp

This patch partly reverts the change that was made in 5f1ba3a502
regarding the clock selection on Apple platforms. It turns out that
gettimeofday() is marked as obsolete by POSIX and clock_gettime() is
recommended instead. Since both are equivalent for our purposes,
prefer using clock_gettime() even on Apple platforms.

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

show more ...

[libc++] Synchronize clock selection between chrono.cpp and filesystem_clock.cpp

Note that _FilesystemClock will now be implemented by calling gettimeofday()
on Apple platforms instead of clock_gett

[libc++] Synchronize clock selection between chrono.cpp and filesystem_clock.cpp

Note that _FilesystemClock will now be implemented by calling gettimeofday()
on Apple platforms instead of clock_gettime(). However, since both are
equivalent, this should not change the behavior on Apple platforms.
There should be no behavior change on other platforms.

In addition to being a consistency clean up, this fixes some issues seen
by folks as reported in https://reviews.llvm.org/D154390#4471924.

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

show more ...

[libc++] Granularize system_error.

Reviewed By: #libc, philnik

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

[libc++] Clean up old macOS back-deployment workarounds

This patch bumps the minimum macOS version for building the dylib
or back-deploying a statically-linked libc++ from macOS 10.11 to
macOS 10.13

[libc++] Clean up old macOS back-deployment workarounds

This patch bumps the minimum macOS version for building the dylib
or back-deploying a statically-linked libc++ from macOS 10.11 to
macOS 10.13. AFAICT, Chrome was the last one to require macOS 10.11,
but since then they have bumped their minimal supported version to
macOS 10.13.

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

show more ...

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/inclu

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

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

show more ...

[libcxx] Use Fuchsia-native monotonic clock for std::chrono::steady_clock

Use the zx_clock_get_monotonic system call directly rather than
going through the POSIX clock_gettime function. The libc fu

[libcxx] Use Fuchsia-native monotonic clock for std::chrono::steady_clock

Use the zx_clock_get_monotonic system call directly rather than
going through the POSIX clock_gettime function. The libc function
is a trivial wrapper around the system call, and is not a standard C
function. Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.

Reviewed By: phosek, ldionne, #libc

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

show more ...

[libc++] Change workaround for init_priority((100)) outside of system headers

We had previously been using a different workaround for pretending that
we were inside a system header, however it had s

[libc++] Change workaround for init_priority((100)) outside of system headers

We had previously been using a different workaround for pretending that
we were inside a system header, however it had some undesirable effects
on dependency parsing for build systems, as explained in [1].

This patch changes the workaround to use `#pragma GCC system_header`,
which shouldn't suffer from the same issue. Unfortunately, it is a lot
more verbose. The issue is that `#pragma GCC system_header` is ignored
when we are inside a source file, so we have to create a header just for
the sake of using it. IMO this seems like an artificial restriction
without much benefit, but investigating that is a different story.
For now, this should at least solve build system problems at the
cost of some readability.

[1]: https://reviews.llvm.org/D95972#3178968

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

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

[libcxx] Fix a missed case needing "system header" markings for init_priority(100)

This was missed in D95972 / 7c49052b170f76f19be64a5572d31ad8f5df4e61,
as this codepath isn't exercised by CI yet.

[libcxx] Fix a missed case needing "system header" markings for init_priority(100)

This was missed in D95972 / 7c49052b170f76f19be64a5572d31ad8f5df4e61,
as this codepath isn't exercised by CI yet.

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

show more ...

[libcxx] Use GetSystemTimePreciseAsFileTime() if available

We will try to use GetSystemTimePreciseAsFileTime if possible.
Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/59195b2d7fe26549

[libcxx] Use GetSystemTimePreciseAsFileTime() if available

We will try to use GetSystemTimePreciseAsFileTime if possible.
Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/59195b2d7fe26549f70969b0dd487293819f023e/.

Reviewed By: compnerd, #libc, mstorsjo, ldionne

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

show more ...

[libcxx] Fix a case of -Wundef warnings regarding _POSIX_TIMERS

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

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

Differential Revis

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

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

show more ...

[SystemZ][ZOS] Provide CLOCK_MONOTONIC alternative

We need CLOCK_MONOTONIC equivalent implementation for z/OS within libc++. The default implementation is asserting.

On z/OS the lack of 'clock_get

[SystemZ][ZOS] Provide CLOCK_MONOTONIC alternative

We need CLOCK_MONOTONIC equivalent implementation for z/OS within libc++. The default implementation is asserting.

On z/OS the lack of 'clock_gettime()' and 'time_point()' force us to look for alternatives.
The current proposal is to use `gettimeofday()` for CLOCK_MONOTONIC which is also used in CLOCK_REALTIME. This will allow us to skip the assertion with compromised CLOCK_MONOTONIC implementation which will not guarantee to never go back in time because it will use `gettimeofday()` but only when it's set.

Is this a good compromise for platforms which does not support monotonic clock?
Hopefully this will spark the discussion and agreement how to proceed in this situation.

Reviewed By: #libc, ldionne, hubert.reinterpretcast

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

show more ...

[libc++] Bring back mach_absolute_time implementation of steady_clock

This is meant to unblock Chrome, as discussed in https://llvm.org/D74489.

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