On Apple platforms, using system-libcxxabi as an ABI library wouldn't
work because we'd try to re-export symbols from libc++abi that the
system libc++abi.dylib might not have. Instead, only re-export those
symbols when we're using the in-tree libc++abi.
This does mean that libc++.dylib won't re-export any libc++abi symbols
when building against the system libc++abi, which could be fixed in
various ways. However, the best solution really depends on the intended
use case, so this patch doesn't try to solve that problem.
As a drive-by, also improve the diagnostic message when the user forgets
to set the LIBCXX_CXX_ABI_INCLUDE_PATHS variable, which would previously
lead to a confusing error.
Closes#104672
(cherry picked from commit 21da4e7f51c7adfd0b1c5defc8bd0d16ea1ce759)
In 6a884a9aef39, I synchronized the export list of libc++abi to the
export list of libc++. From the linker's perspective, this caused these
symbols to be taken from libc++.dylib instead of libc++abi.dylib.
However, that can be problematic when back-deploying. Indeed, this means
that the linker will encode an undefined reference to be fullfilled by
libc++.dylib, but when backdeploying against an older system, that
symbol might only be available in libc++abi.dylib.
Most of the symbols that started being re-exported after 6a884a9aef39
turn out to be implementation details of libc++abi, so nobody really
depends on them and this back-deployment issue is inconsequential.
However, we ran into issues with a few of these symbols while testing
LLVM 19, which led to this patch. This slipped between the cracks and
that is why the patch is coming so long after the original patch landed.
In the future, a follow-up cleanup would be to stop exporting most of
the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
since they are implementation details that nobody should be relying on.
rdar://131984512
(cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c)
Until https://github.com/llvm/llvm-project/pull/103056 lands
or another more appropriate check can be found.
This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.
Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.
(cherry picked from commit 6f6422f4a2b8647a59936c131e50a79906d89510)
The CI has been a complete mess for the past week, and the only thing
preventing it from being back is the Clang tidy checks. Disable them (as
a total hack) to get CI back.
(cherry picked from commit 78c6506543dee13c9335edc5c85bc73c4853fbd7)
Pull request #96032 unconditionall adds the `cwchar` include in the
`format` umbrella header. However support for wchar_t can be disabled in
the build system (LIBCXX_ENABLE_WIDE_CHARACTERS).
This patch guards against inclusion of `cwchar` in `format` by checking
the `_LIBCPP_HAS_NO_WIDE_CHARACTERS` define.
For clarity I've also merged the include header section that `cwchar`
was in with the one above as they were both guarded by the same `#if`
logic.
(cherry picked from commit ec56790c3b27df4fa1513594ca9a74fd8ad5bf7f)
We were using a `_LIBCPP_ASSERT_FOO` macro without including `<__assert>`.
rdar://134425695
(cherry picked from commit 0df78123fdaed39d5135c2e4f4628f515e6d549d)
Trying to copy-construct a std::span from another std::span holding an
incomplete type would fail as we evaluate the SFINAE for the range-based
constructor. The problem was that we checked for __is_std_span after
checking for the range being a contiguous_range, which hard-errored
because of arithmetic on a pointer to incomplete type.
As a drive-by, refactor the whole test and format it.
Fixes#104496
(cherry picked from commit 99696b35bc8a0054e0b0c1a26e8dd5049fa8c41b)
This is in relation to mr #93350. It was merged to main, but reverted
because of failing sanitizer builds on PowerPC.
The fix includes replacing the hard-coded threshold constants (e.g.
`__overflow_threshold`) for different floating-point sizes by a general
computation using `std::ldexp`. Thus, it should now work for all architectures.
This has the drawback of not being `constexpr` anymore as `std::ldexp`
is not implemented as `constexpr` (even though the standard mandates it
for C++23).
Closes#92782
(cherry picked from commit 72825fde03aab3ce9eba2635b872144d1fb6b6b2)
This reverts commit 9628777479a970db5d0c2d0b456dac6633864760.
More details in https://github.com/llvm/llvm-project/pull/93350, but
this broke the PowerPC sanitizer bots.
(cherry picked from commit 1031335f2ee1879737576fde3a3425ce0046e773)
Remove `XFAIL: LIBCXX-AIX-FIXME` from lit test `transform.pass.cpp` now
that AIX system call `wcsxfrm`/`wcsxfrm_l` is fixed in AIX 7.2.5.8 and
7.3.2.2 and buildbot machines have been upgraded.
Backported from commit cb5912a71061c6558bd4293596dcacc1ce0ca2f6
Investigating #96612 shows our implementation was different from the
Standard and could cause UB. Testing the codegen showed quite a bit of
assembly generated for these functions. The functions have been written
differently which allows Clang to optimize the code to use simple CPU
rotate instructions.
Fixes: https://github.com/llvm/llvm-project/issues/96612
This patch fixes/unifies AIX target triples used in libc++, libc++abi,
and libunwind LIT tests.
(cherry picked from commit 2d3655037ccfa276cb0949c2ce0cff56985f6637)
This patch increases the alignment requirement for std::atomic_ref
such that we can guarantee lockfree operations more often. Specifically,
we require types that are 1, 2, 4, 8, or 16 bytes in size to be aligned
to at least their size to be used with std::atomic_ref.
This is the case for most types, however a notable exception is
`long long` on x86, which is 8 bytes in length but has an alignment
of 4.
As a result of this patch, one has to be more careful about the
alignment of objects used with std::atomic_ref. Failure to provide
a properly-aligned object to std::atomic_ref is a precondition
violation and is technically UB. On the flipside, this allows us
to provide an atomic_ref that is actually lockfree more often,
which is an important QOI property.
More information in the discussion at https://github.com/llvm/llvm-project/pull/99570#issuecomment-2237668661.
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
(cherry picked from commit 59ca618e3b7aec8c32e24d781bae436dc99b2727)
This reverts commit 55357160d0e151c32f86e1d6683b4bddbb706aa1.
This is only being reverted from the LLVM 19 branch as a
convenience to avoid breaking some IDEs which were not ready
for that change.
Fixes#99464
This patch applies the comments provided on #84573. This is done as a
separate PR to avoid merge conflicts with downstreams that already had
ptrauth support.
(cherry picked from commit e64e745e8fb802ffb06259b1a5ba3db713a17087)
The builtin __atomic_always_lock_free takes into account the type of the
pointer provided as the second argument. Because we were passing void*,
rather than T*, the calculation failed. This meant that
atomic_ref<T>::is_always_lock_free was only true for char & bool.
This bug exists elsewhere in the atomic library (when using GCC, we fail
to pass a pointer at all, and we fail to correctly align the atomic like
_Atomic would).
This change also attempts to start sorting out testing difficulties with
this function that caused the bug to exist by using the
__GCC_ATOMIC_(CHAR|SHORT|INT|LONG|LLONG|POINTER)_IS_LOCK_FREE predefined
macros to establish an expected value for `is_always_lock_free` and
`is_lock_free` for the respective types, as well as types with matching
sizes and compatible alignment values.
Using these compiler pre-defines we can actually validate that certain
types, like char and int, are actually always lock free like they are on
every platform in the wild.
Note that this patch was actually authored by Eric Fiselier but I picked
up the patch and GitHub won't let me set Eric as the primary author.
Co-authored-by: Eric Fiselier <eric@efcs.ca>
(cherry picked from commit cc1dfb37aa84d1524243b83fadb8ff0f821e03e9)
The `<locale>` header uses `strtoll_l` and friends which are defined in
`<xlocale.h>` on these platforms. While this works via transitive
includes when modules are disabled, this doesn't work anymore if the
platforms are modularized properly.
(cherry picked from commit a55df237375e98cfc2520d5eb1a23b302ef02ba0)
This implements the requirements for the container iterator requirements
for array, deque, vector, and `vector<bool>`.
Implements:
- LWG3352 strong_equality isn't a thing
Implements parts of:
- P1614R2 The Mothership has Landed
Fixes: https://github.com/llvm/llvm-project/issues/62486
This ensures that shrink_to_fit does not increase the allocated size.
Partly addresses #95161
(cherry picked from commit d0ca9f23e8f25b0509c3ff34ed215508b39ea6e7)
`vector<bool>`'s shrink_to_fit implementation is using the
"swap-to-free-container-resources-trick" which only shrinks when the
input vector is empty. Since the request to shrink_to_fit is
non-binding, this is a valid implementation. It is not a high-quality
implementation. Since `vector<bool>` is not a very popular container the
implementation has not been changed and only a test to validate the
non-growing property has been added.
This was discovered while investigating #95161.
(cherry picked from commit c2e438675754b83c31d7d5ba40cb13fe77e795de)
The 3-dimentionsional `std::hypot(x,y,z)` was sub-optimally implemented.
This lead to possible over-/underflows in (intermediate) results which
can be circumvented by this proposed change.
The idea is to to scale the arguments (see linked issue for full
discussion).
Tests have been added for problematic over- and underflows.
Closes#92782
(cherry picked from commit 9628777479a970db5d0c2d0b456dac6633864760)
~~NB: This PR depends on #78876. Ignore the first commit when reviewing,
and don't merge it until #78876 is resolved. When/if #78876 lands, I'll
clean this up.~~
This partially restores parity with the old, since removed debug build.
We now can re-enable a bunch of the disabled tests. Some things of note:
- `bounded_iter`'s converting constructor has never worked. It needs a
friend declaration to access the other `bound_iter` instantiation's
private fields.
- The old debug iterators also checked that callers did not try to
compare iterators from different objects. `bounded_iter` does not
currently do this, so I've left those disabled. However, I think we
probably should add those. See
https://github.com/llvm/llvm-project/issues/78771#issuecomment-1902999181
- The `std::vector` iterators are bounded up to capacity, not size. This
makes for a weaker safety check. This is because the STL promises not to
invalidate iterators when appending up to the capacity. Since we cannot
retroactively update all the iterators on `push_back()`, I've instead
sized it to the capacity. This is not as good, but at least will stop
the iterator from going off the end of the buffer.
There was also no test for this, so I've added one in the `std`
directory.
- `std::string` has two ambiguities to deal with. First, I opted not to
size it against the capacity. https://eel.is/c++draft/string.require#4
says iterators are invalidated on an non-const operation. Second,
whether the iterator can reach the NUL terminator. The previous debug
tests and the special-case in https://eel.is/c++draft/string.access#2
suggest no. If either of these causes widespread problems, I figure we
can revisit.
- `resize_and_overwrite.pass.cpp` assumed `std::string`'s iterator
supported `s.begin().base()`, but I see no promise of this in the
standard. GCC also doesn't support this. I fixed the test to use
`std::to_address`.
- `alignof.compile.pass.cpp`'s pointer isn't enough of a real pointer.
(It needs to satisfy `NullablePointer`, `LegacyRandomAccessIterator`,
and `LegacyContiguousIterator`.) `__bounded_iter` seems to instantiate
enough to notice. I've added a few more bits to satisfy it.
Fixes#78805
The Android Emulator has started printing this message, so pass the
`-no-metrics` option:
```
##############################################################################
## WARNING - ACTION REQUIRED ##
## Consider using the '-metrics-collection' flag to help improve the ##
## emulator by sending anonymized usage data. Or use the '-no-metrics' ##
## flag to bypass this warning and turn off the metrics collection. ##
## In a future release this warning will turn into a one-time blocking ##
## prompt to ask for explicit user input regarding metrics collection. ##
## ##
## Please see '-help-metrics-collection' for more details. You can use ##
## '-metrics-to-file' or '-metrics-to-console' flags to see what type of ##
## data is being collected by emulator as part of usage statistics. ##
##############################################################################
```
## Introduction
This patch implements LWG3618: Unnecessary `iter_move` for
`transform_view::iterator`.
`transform_view`'s iterator currently specifies a customization point
for `iter_move`. This customization point does the same thing that the
default implementation would do, but its sole purpose is to ensure the
appropriate conditional `noexcept` specification.
## Reference
-
[[range.transform.iterator]](https://eel.is/c++draft/range.transform.iterator)
- [LWG3618](https://cplusplus.github.io/LWG/issue3618)
This makes `std::pair` trivially copyable if its members are and we have
a way to do so. We need either C++20 with requires clauses or support
for `__attribute__((enable_if))`. Only Clang has support for this
attribute, so it's effectively clang or C++20.
Co-authored-by: Christopher Di Bella <cjdb@google.com>
Implements parts of:
- P0355 Extending to chrono Calendars and Time Zones
- P1361 Integration of chrono with text formatting
- P2372 Fixing locale handling in chrono formatters
Implementing the Hermite polynomials which are part of C++17's
mathematical special functions. The goal is to get early feedback which
will make implementing the other functions easier. Integration of
functions in chunks (e.g. `std::hermite` at first, then `std::laguerre`,
etc.) might make sense as well (also see note on boost.math below).
I started out from this abandoned merge request:
https://reviews.llvm.org/D58876 .
The C++23 standard defines them in-terms of `/* floating-point type */`
arguments. I have not looked into that.
Note, there is still an ongoing discussion on discourse whether
importing boost.math is an option.
This assures shrink_to_fit does not increase the allocated size.
Partly addresses https://github.com/llvm/llvm-project/issues/95161
---------
Co-authored-by: Mital Ashok <mital.vaja@googlemail.com>
