[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

[libcxx] Avoid overflows in the windows __libcpp_steady_clock_now()

As freq.QuadValue can be in the range of 10000000 to 19200000,
the multiplication before division makes the calculation overflow
a

[libcxx] Avoid overflows in the windows __libcpp_steady_clock_now()

As freq.QuadValue can be in the range of 10000000 to 19200000,
the multiplication before division makes the calculation overflow
and wrap to negative values every 16-30 minutes.

Instead count the whole seconds separately before adding the
scaled fractional seconds.

Add a testcase for steady_clock to check that the values returned for
now() compare as bigger than the zero time origin; this
corresponds to a testcase in Qt [1] [2] (that failed spuriously
due to this).

[1] https://bugreports.qt.io/browse/QTBUG-89539
[2] https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/kernel/qdeadlinetimer/tst_qdeadlinetimer.cpp?id=f8de5e54022b8b7471131b7ad55c83b69b2684c0#n569

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

show more ...

[libc++] NFCI: Refactor chrono.cpp to make it easier to support new platforms

Also simplify a few conditionals along the way for readability.

[libc++] Check _LIBCPP_USE_CLOCK_GETTIME before using clock_gettime

The clock_gettime function is available when _POSIX_TIMERS is defined.
We check for this and set _LIBCPP_USE_CLOCK_GETTIME accordi

[libc++] Check _LIBCPP_USE_CLOCK_GETTIME before using clock_gettime

The clock_gettime function is available when _POSIX_TIMERS is defined.
We check for this and set _LIBCPP_USE_CLOCK_GETTIME accordingly since
59b3102739c. But check for _LIBCPP_USE_CLOCK_GETTIME was removed in
babd3aefc91. As a result, code is now trying to use clock_gettime even
on platforms where it is not available and it is causing build failure
with newlib.

This patch restores the checks to fix this.

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

show more ...

[libc++] Remove workarounds for the lack of clock_gettime on older macOS platforms

This increases the Mac OS requirement for building libc++ to 10.12.
Note that it doesn't change whether the *header

[libc++] Remove workarounds for the lack of clock_gettime on older macOS platforms

This increases the Mac OS requirement for building libc++ to 10.12.
Note that it doesn't change whether the *headers* still support older
platforms -- it's only that macOS >= 10.12 is required to build the
dylib from sources.

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

show more ...

[libc++] Adjust how we guard the inclusion of unistd.h

unistd.h isn't guaranteed to exist when the target isn't Windows, in
particular if the target is bare-metal (i.e. no operating system).
Handle

[libc++] Adjust how we guard the inclusion of unistd.h

unistd.h isn't guaranteed to exist when the target isn't Windows, in
particular if the target is bare-metal (i.e. no operating system).
Handle this by using __has_include instead, though in
filesystem/operations.cpp we already unconditionally include it so
just remove the extra include.

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

show more ...

[libc++] chrono: check _POSIX_TIMERS before using clock_gettime

clock_gettime is documented to be available when _POSIX_TIMERS is
defined. Add a check for this.

Differential Revision: https://revie

[libc++] chrono: check _POSIX_TIMERS before using clock_gettime

clock_gettime is documented to be available when _POSIX_TIMERS is
defined. Add a check for this.

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

show more ...

[libc++] NFC: Remove outdated #if comment

[libc++][Apple] Use CLOCK_MONOTONIC_RAW instead of CLOCK_UPTIME_RAW for steady_clock

Summary:
In D27429, we switched the Apple implementation of steady_clock::now()
from clock_gettime(CLOCK_MONOTONI

[libc++][Apple] Use CLOCK_MONOTONIC_RAW instead of CLOCK_UPTIME_RAW for steady_clock

Summary:
In D27429, we switched the Apple implementation of steady_clock::now()
from clock_gettime(CLOCK_MONOTONIC) to clock_gettime(CLOCK_UPTIME_RAW).
The purpose was to get nanosecond precision, and also to improve the
performance of the implementation.

However, it appears that CLOCK_UPTIME_RAW does not satisfy the requirements
of the Standard, since it is not strictly speaking monotonic. Indeed, the
clock does not increment while the system is asleep, which had been
mentioned in D27429 but somehow not addressed.

This patch switches to CLOCK_MONOTONIC_RAW, which is monotonic, increased
during sleep, and also has nanosecond precision.

https://llvm.org/PR44773

Reviewers: bruno, howard.hinnant, EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF

Tags: #libc

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

show more ...

[libcxx{,abi}] Emit deplibs only when detected by CMake

This is a followup to 35bc5276ca3. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
d

[libcxx{,abi}] Emit deplibs only when detected by CMake

This is a followup to 35bc5276ca3. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
detects them, rather than based on explicit platform blacklist.

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

show more ...

[libcxx][NFC] Strip trailing whitespace, fix typo.

[runtimes] Don't depend on libpthread on Android

r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Andro

[runtimes] Don't depend on libpthread on Android

r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.

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

llvm-svn: 366734

show more ...

[runtimes] Check if pragma comment(lib, ...) is supported first

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is C

[runtimes] Check if pragma comment(lib, ...) is supported first

This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.

llvm-svn: 362055

show more ...

[runtimes] Support ELF dependent libraries feature

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthr

[runtimes] Support ELF dependent libraries feature

As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.

This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.

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

llvm-svn: 362048

show more ...

Fix typo that I introduced in r357413. Thanks to [email protected] for the catch.

llvm-svn: 357474

Fix PR#41323 'Race condition in steady_clock::now for _LIBCPP_WIN32API'. thanks to Ivan Afanasyev for the report.

llvm-svn: 357413