This tests seems problematic on different platforms. There is still a
test that ensures coverage, but in an automatic fashion. This test needs
to be investigated.
According to our synopsis it belonged to ios_fwd. This is not true in
the C++11 version of the Standard, I did not validate against C++98.
Moving this to ios's forward where it's declared in the standard allows
removing a module quirk. An earlier removal of std::vectors forward
declaration allows to remove all quirks for the iosfwd module part.
Since iosfwd includes __fwd/ios.h this does not change the required
includes.
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 deprecates support for the synchronization
library before C++20. In the next release, we can remove that support
entirely.
This patch uses our availability machinery to allow defining a key
function for bad_function_call and bad_expected_access at all times but
only rely on it when we can. This prevents compilers from complaining
about weak vtables and reduces code bloat and the amount of work done by
the dynamic linker.
rdar://111917845
Functions inside __cpu_traits were needlessly prefixed with __parallel,
which doesn't serve a real purpose anymore now that they are inside a
traits class.
This enables testing of the LLDB libc++ specific data formatters.
This is enabled in the bootstrap build since building LLDB requires
Clang and this
is quite expensive. Adding this test changes the build time from 31 to
34 minutes.
In the future, this utility could be made to also work with iterators,
including bounded iterators. We could also query the ASAN runtime for
this information when it's around.
Currently, CPU backends in the PSTL are created by defining functions
in the __par_backend namespace. Then, the PSTL includes the CPU backend
that gets configured via CMake and gets those definitions.
This prevents CPU backends from easily co-existing and is a bit
confusing.
To solve this problem, this patch introduces the notion of __cpu_traits,
which is a cheap encapsulation of the basis operations required to
implement a CPU-based PSTL. Different backends can now define their own
tag and coexist, and the CPU-based PSTL will simply use __cpu_traits to
dispatch to the right implementation of e.g. __for_each.
Note that this patch doesn't change the actual implementation of the
backends in any way, it only modifies how that implementation is
accessed
to implement PSTL algorithms.
This patch is a step towards #88131.
This is a relatively low cost way of reducing the include sizes in older
language modes compared to the effect. For example, in C++14 mode the
include time of `<algorithm>` is reduced from 198ms to 127ms.
The work-around in 26852565a5f609e6b466f43c2f690ce3047d04c7 didn't fix
the CI. Since the entire local database is compared with the libc++
implementation in a separate this this change does not remove coverage.
LWG3869 Deprecate std::errc constants related to UNIX STREAMS
deprecates the POSIX macros ENODATA, ENOSR, ENOSTR, and ETIME. These
were deprecated in libc++ in
https://github.com/llvm/llvm-project/pull/80542. Based on the post
commit feedback the macro are no longer deprecated. Instead libc++
leaves the deprecation to the provider of errno.h.
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
The overhead of taking a std::mutex is much lower than taking a reader
lock on a shared mutex, even under heavy contention.
The benefit of shared_mutex only occurs as the amount of
time spent in the critical sections grows large enough.
In our case all we do is read a pointer and return the lock.
As a result, using a shared lock can be ~50%-100% slower
Here are the results for the provided benchmark on my machine:
```
2024-04-07T12:48:51-04:00
Running ./libcxx/benchmarks/shared_mutex_vs_mutex.libcxx.out
Run on (12 X 400 MHz CPU s)
CPU Caches:
L1 Data 32 KiB (x6)
L1 Instruction 32 KiB (x6)
L2 Unified 1024 KiB (x6)
L3 Unified 32768 KiB (x1)
Load Average: 2.70, 2.70, 1.63
---------------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------------
BM_shared_mutex/threads:1 13.9 ns 13.9 ns 50533700
BM_shared_mutex/threads:2 34.5 ns 68.9 ns 9957784
BM_shared_mutex/threads:4 38.4 ns 137 ns 4987772
BM_shared_mutex/threads:8 51.1 ns 358 ns 1974160
BM_shared_mutex/threads:32 57.1 ns 682 ns 1043648
BM_mutex/threads:1 5.54 ns 5.53 ns 125867422
BM_mutex/threads:2 15.5 ns 30.9 ns 21830116
BM_mutex/threads:4 15.4 ns 57.2 ns 12136920
BM_mutex/threads:8 19.3 ns 140 ns 4997080
BM_mutex/threads:32 20.8 ns 252 ns 2859808
```
## Abstract
This pull request implements [P3029R1](https://wg21.link/P3029R1). The
paper discusses the current behavior of `mdspan`'s most common
pointer-indices CTAD, where the `Extents` template parameter is deduced
as `dextents` (dynamic extents), even when passing compile-time constant
values. The author believes this behavior is suboptimal, as it doesn't
take advantage of the compile-time information. The proposed change
suggests deducing static extents if `integral_constant`-like constants
are passed, resulting in more intuitive syntax and less error-prone
code.
## Reference
- [P3029R1](https://wg21.link/P3029R1)
- [Draft C++ Standard: [span.syn]](https://eel.is/c++draft/span.syn)
- [Draft C++ Standard: [mdspan.syn]](https://eel.is/c++draft/mdspan.syn)
This pull request implements LWG3643: Missing constexpr in
std::counted_iterator. Specifically, one overload of
std::counted_operator::operator++ was not marked as constexpr,
despite being eligible for it after the introduction of try-block
support in constexpr functions in C++20.
As reported in #86843, we must have #pragma GCC system_header before we
use #include_next, otherwise the compiler may not understand that we're
in a system header and may issue a diagnostic for our usage of
Instead of instantiating `__copy_cv` for every combination of `_From`
and `_To` this only instantiates `__copy_cv` for every `_From` type,
reducing the number of instantiations.
Fixes#86556
Use `__builtin_popcountg` instead of `__buildin_popcount{l|ll}`
Use `__builtin_clzg instead` of `__buildin_clz{l|ll}`
Use `__builtin_ctzg instead` of `__builtin_ctz{l|ll}`
The generic variant of the builtins can be used to simplify some logic
with >= Clang 19 or >= GCC 14, where these generic variants are
available. As for backwards compatibility reasons, we can't completely
remove the old logic. Therefore, I left ToDo comments to address this,
as soon as support for pre Clang 19 as well as pre GCC 14 is dropped.
---------
Co-authored-by: Nick Desaulniers <nickdesaulniers@users.noreply.github.com>
In order to test the LLDB data formatters make is required and SWIG
needs to be updated to version 4.
As drive-by, this patch sorts the entries and removes some duplicates.
Adds the sys_info class and time_zone::get_info(). The code still has a
few quirks and has not been optimized for performance yet.
The returned sys_info is compared against the output of the zdump tool
in the test giving confidence the implementation is correct.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Implements:
- LWGXXXX The sys_info range should be affected by save
The path /etc/localtime is a symlink. This symlink can be a relative
path. This fixes resolving a relative symlink.
Since the path used is hard-coded based on the user's system there is no
good way to test this.
Fixes: https://github.com/llvm/llvm-project/issues/87872
This adds an initial fuzzer. Different formatting arguments will execute
different code paths. This will be tested by different fuzzer tests.
The code is based on a sample provided by Louis.
This was actually already implemented in the initial version of
std::expected, but this patch adds test coverage and makes it more
explicit that we intend to make these functions noexcept.
The application of constexpr to __construct_at triggers weird linker
errors when building LLVM with modules enabled and C++ < 20.
> ld.lld: error: undefined hidden symbol: void*
std::__1::__voidify[abi:nn190000]<llvm::sys::ProcessStatistics>(llvm::sys::ProcessStatistics&)
>>>> referenced by construct_at.h:52
(/usr/local/bin/../include/c++/v1/__memory/construct_at.h:52)
>>>> Program.cpp.o:(llvm::sys::Wait(llvm::sys::ProcessInfo const&,
std::__1::optional<unsigned int>, std::__1::basic_string<char,
std::__1::char_traits<char>, std::__1::allocator<char>>*,
std::__1::optional<llvm::sys::ProcessStatistics>*, bool)) in archive
lib/libLLVMSupport.a
I suspect this is related to undefined behavior caused by the fact that
construct_at is never really constexpr (which is UB NDR).
I'm unsure how to meaningfully write a test for this, as I haven't been
able to trigger it in smaller unit tests
__precision_ is declared as an int32_t which on some hexagon platforms
is defined as a long.
This change fixes errors like the ones below:
In file included from
/local/mnt/workspace/hex/llvm-project/libcxx/test/libcxx/diagnostics/format.nodiscard_extensions.compile.pass.cpp:19:
In file included from
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/format:202:
In file included from
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:29:
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/formatter_floating_point.h:700:17:
error: no matching function for call to 'max'
700 | int __p = std::max(1, (__specs.__has_precision() ?
__specs.__precision_ : 6));
| ^~~~~~~~
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/formatter_floating_point.h:771:25:
note: in instantiation of function template specialization
'std::__formatter::__format_floating_point<float, char,
std::format_context>' requested here
771 | return __formatter::__format_floating_point(__value, __ctx,
__parser_.__get_parsed_std_specifications(__ctx));
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:284:42:
note: in instantiation of function template specialization
'std::__formatter_floating_point<char>::format<float,
std::format_context>' requested here
284 | __ctx.advance_to(__formatter.format(__arg, __ctx));
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:429:15:
note: in instantiation of function template specialization
'std::__vformat_to<std::back_insert_iterator<std::string>, char,
std::back_insert_iterator<std::__format::__output_buffer<char>>>'
requested here
429 | return std::__vformat_to(std::move(__out_it), __fmt, __args);
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:462:8:
note: in instantiation of function template specialization
'std::vformat_to<std::back_insert_iterator<std::string>>' requested here
462 | std::vformat_to(std::back_inserter(__res), __fmt, __args);
| ^
/local/mnt/workspace/hex/llvm-project/libcxx/test/libcxx/diagnostics/format.nodiscard_extensions.compile.pass.cpp:29:8:
note: in instantiation of function template specialization
'std::vformat<void>' requested here
29 | std::vformat("", std::make_format_args());
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:35:1:
note: candidate template ignored: deduced conflicting types for
parameter '_Tp' ('int' vs. 'int32_t' (aka 'long'))
35 | max(_LIBCPP_LIFETIMEBOUND const _Tp& __a, _LIBCPP_LIFETIMEBOUND
const _Tp& __b) {
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:43:1:
note: candidate template ignored: could not match
'initializer_list<_Tp>' against 'int'
43 | max(initializer_list<_Tp> __t, _Compare __comp) {
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:48:86:
note: candidate function template not viable: requires single argument
'__t', but 2 arguments were provided
48 | _LIBCPP_NODISCARD_EXT inline _LIBCPP_HIDE_FROM_ABI
_LIBCPP_CONSTEXPR_SINCE_CXX14 _Tp max(initializer_list<_Tp> __t) {
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:29:1:
note: candidate function template not viable: requires 3 arguments, but
2 were provided
29 | max(_LIBCPP_LIFETIMEBOUND const _Tp& __a, _LIBCPP_LIFETIMEBOUND
const _Tp& __b, _Compare __comp) {
| ^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
