Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
This patch fixes the test `force_thread_creation_failure.cpp` on AIX by
using platform specific `RLIMIT_THREADS` which helps in restricting the
thread creation as `RLIMIT_NPROC` on AIX restricts processes and not
threads.
---------
Co-authored-by: himadhith <himadhith.v@ibm.com>
The overloaded `operator&` caused non-conforming behavior when
- using `operator==` to compare "addresses" of proxy reference objects,
and
- relying on the exact type of `&ref`.
No deprecation warning is added, becaue it should be portable to write
`&ref` where `ref` is a proxy reference variable, and this patch just
corrects the behavior.
`__bit_const_reference::operator&` is kept, because when one defines
`_LIBCPP_ABI_BITSET_VECTOR_BOOL_CONST_SUBSCRIPT_RETURN_BOOL` to make the
libc++ implementation strategy conforming, the `operator&` will never be
exposed to users.
This reverts commits 30084d74765c and 5b8c17580482. The second commit
was landed without proper review: not by fault of the submitter, but
because I mistakenly thought this was modifying something else entirely
that is unsupported. The first commit must also be reverted because it
is a breaking change without the second commit.
This corresponds to PRs #183223 and #188660, see those for more details.
There was one more const_cast needed after #183223 without which
copy assignment of hash_map was broken. Add it, together with a copy
assignment test.
Reviewers: ldionne
Pull Request: https://github.com/llvm/llvm-project/pull/188660
An unintended change in #134045 gave them a default template argument,
which is supposed to be from C++14 onwards.
I considered adding a test for this but it is really awkward to test
that we don't support passing no template argument in C++03 mode and
that provides little value, so I decided against it.
This PR introduces a `std::__is_sufficiently_aligned` helper function that
can be used for the `atomic_ref` C++20 constructors while the public
C++26 `std::is_sufficiently_aligned` delegates to the new helper
function.
Fixes#179803
Assisted-by: Claude Code
Signed-off-by: mlevine55 <mlevine55@bloomberg.net>
Pointer field protection has the following characteristics:
- Pointer fields in RTTI types are unsigned. Signing these fields
is unnecessary because PFP is a mechanism for protecting the heap,
and the RTTI objects typically live in global variables. Therefore,
mark the fields with the no_field_protection to inhibit PFP for these
fields.
- libcxx's interim trivial relocatability implementation, which memcpy's
some non-trivially-copyable objects according to the value of a trait,
conflicts with PFP in tagged mode (in which the address of the pointer
is used as part of the pointer encoding) by causing such copies to
result in a crash in some cases where the object being copied includes
a pointer field. These copies are undefined behavior. Therefore, make
libcxx's trivially relocatable predicate simply return the value of
the trivially copyable trait when PFP in tagged mode is enabled, which
results in standards compliant behavior that is accommodated by PFP.
Reviewers: philnik777, fmayer, ldionne
Pull Request: https://github.com/llvm/llvm-project/pull/151651
Introduce CMake option `LIBCXX_HAS_C11_THREAD_API` that explicitly
instructs libc++ to use C11 threads. Make sure
`_LIBCPP_HAS_THREAD_API_C11` is defined properly in the
`<__config_site>` and interacts correctly with platform-based
auto-selection of thread API when it's not explicitly set.
Resolves#186801
Removed the non-standard member type `iterator_type` from `__wrap_iter`.
This member exposed the underlying iterator type, and its removal
prevents users from relying on the implementation detail.
The type `__gnu_cxx::hash_{,multi}map` creates objects of type
`std::pair<Key, Value>` and returns pointers to them of type
`std::pair<const Key, Value>`. If either `Key` or `Value` are
non-standard-layout, this is UB, and is furthermore considered by
pointer field protection to be a type confusion, which leads to a
program crash. Fix it by using the correct type for the pair's storage
and using const_cast to form a pointer to the key in the one place where
that is needed.
Reviewers: ldionne
Reviewed By: ldionne
Pull Request: https://github.com/llvm/llvm-project/pull/183223
Since befaa35212dbaac39cd76a8dc748e4df7c90a0d9, the CI stably failed for
the generic-no-wide-characters build, because in no-`wchar_t` modes, the
header for `__remove_cv_t` wasn't properly included.
This PR adds the missing include of `<__type_traits/remove_cv.h>`.
As drive-by, `<__cstddef/size_t.h>` and
`<__type_traits/is_constant_evaluated.h>`, which are included by
`<cwchar>`, are also made included by `<string>` to avoid potential
regression as we're using `size_t` and
`__libcpp_is_constant_evaluated()` in `<string>`.
The frozen C++03 headers got an invalid simplification in #134045 that
changed the signature of random_shuffle to use a forwarding reference
instead of a lvalue reference. This patch fixes it and adds a test.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
In `<version>` and test files, `__cpp_lib_destroying_delete` is already
properly guarded with standard modes, so it's redundant to say standard
revision in `test_suite_guard`/`libcxx_guard`.
As per PEP-0394[1], there is no real concensus over what binary names
Python has, specifically 'python' could be Python 3, Python 2, or not
exist.
However, everyone has a python3 interpreter and the scripts are all
written for Python 3. Unify the shebangs so that the ~50% of shebangs
that use python now use python3.
[1] https://peps.python.org/pep-0394/
Without this, we were assuming that __ulock was unavailable on visionOS
and falling back to the manual implementation, when in reality we can
always rely on the existence of ulock.
Fixes#186467
__is_transparent_v used to accept an additional _Key template argument
whose sole purpose was to make the instantiation as a whole dependent.
It turns out that creates confusion around whether that trait takes into
account the key type (it does not). Instead, we can use our traditional
approach for making template params artificially dependent, which allows
removing the confusing parameter.
For disclaimer, I authored this patch with Claude code just to see if I
could get it to do the right thing. It works, but you have to steer it
right.
Fixes#186417
Renaming from _Tp to _ArgumentType makes it clearer that we're passing
the argument type intended for the comparator, which allows checking
whether *that specific use* of the comparator would be transparent.
Fixes#186396
On AIX, this test sometimes fails with error `Assertion failed: y ==
true`. The test assumes `compare_exchange_weak` should succeed on a
single call, however according to the standard:
> A weak compare-and-exchange operation may fail spuriously. That is,
even when the contents of memory referred to by expected and ptr are
equal, it may return false and store back to expected the same memory
contents that were originally there.
This spurious failure enables implementation of compare-and-exchange on
a broader class of machines, e.g., load-locked store-conditional
machines. A consequence of spurious failure is that nearly all uses of
weak compare-and-exchange will be in a loop.
[atomics.ref.ops]/27
Currently the query benchmarks are training the branch predictor
incredibly well, which isn't representative of the real world. This
change causes the branch misses to go from <1% to ~50% with the current
implementation of `__tree::__find_end`.
This patch also removes the `non-existent` benchmarks, since it'd be
non-trivial to write a representative benchmark for that case, and the
benchmark would be relatively low value. We're already searching to leaf
nodes ~50% of the time (since half the nodes are leaves) with the
current benchmark. So we'd only additionally cover a relatively trivial
failure branch that is only taken once per function call. The loop is
already covered through benchmarking with keys existing in the
container.
The check whether a stream is associated with a terminal or not and the
flushing of the stream in `std::print()` is needed only on Windows.
Additionally, the correct flush should be used. When `std::print` is
called with a C stream, `std::fflush()` should be used. When it is
called with C++ `ostream`, `ostream::flush()` should be called.
Because POSIX does not have a separate Unicode API for terminal output,
checking for terminal (`isatty`) and flushing is not needed at all.
Moreover, `isatty` has noticeable performance cost.
See also https://wg21.link/LWG4044.
Fixes#70142
In #124103 we changed the size of various iostream objects, which turns
out to be ABI breaking when compiling non-PIE code.
This ABI break is safe to fix, since for any programs allocating more
memory for the iostream objects, the remaining bytes are simply unused
now.
Fixes#185724
This benchmark isn't very good at benchmarking `search_n`, since a good
`search_n` implementation can go through it in ~10 perfectly predictable
steps. We can drop it to avoid spending unnecessary resources. This also
fixes that the two benchmark sets have identical names.
Fixes#183832
`formatter::parse` and `formatter::format` only have to accept
`basic_format_parse_context` and `basic_format_context` respectively,
which are only guaranteed to be provided via `<format>`. This allows us
to only declare the functions for `formatter<bool>` in `<vector>` and
define them if `<format>` is included. This reduces the amount of time
it takes to parse `<vector>` by ~15% on my system.
