| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(#149452)
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
|
|
|
|
This can improve code gen slightly.
|
|
errors." (#148787)
Reverts llvm/llvm-project#148266
I'm reverting this temporarily, since the release branch is today and
this is ABI sensitive. Let's wait until after the branch so that we have
plenty time to discuss the patch.
|
|
(#148266)
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
|
|
Reverts llvm/llvm-project#147146
This is failing to build on our public macOS CI:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake-sanitized/
```
06:48:56 FAILED: libcxx/src/CMakeFiles/cxx_shared.dir/atomic.cpp.o
06:48:56 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/bin/clang++ --target=arm64-apple-darwin23.1.0 -DLIBCXX_BUILDING_LIBCXXABI -DLIBC_NAMESPACE=__llvm_libc_common_utils -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_LIBCPP_BUILDING_LIBRARY -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/libcxx/src -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/include/c++/v1 -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/libcxxabi/include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/cmake/Modules/../../libc -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -O3 -DNDEBUG -std=c++23 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk -mmacosx-version-min=14.1 -fPIC -UNDEBUG -faligned-allocation -nostdinc++ -fvisibility-inlines-hidden -fvisibility=hidden -fsized-deallocation -Wall -Wextra -Wnewline-eof -Wshadow -Wwrite-strings -Wno-unused-parameter -Wno-long-long -Werror=return-type -Wextra-semi -Wundef -Wunused-template -Wformat-nonliteral -Wzero-length-array -Wdeprecated-redundant-constexpr-static-def -Wno-nullability-completeness -Wno-user-defined-literals -Wno-covered-switch-default -Wno-suggest-override -Wno-error -fdebug-prefix-map=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/include/c++/v1=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/libcxx/include -MD -MT libcxx/src/CMakeFiles/cxx_shared.dir/atomic.cpp.o -MF libcxx/src/CMakeFiles/cxx_shared.dir/atomic.cpp.o.d -o libcxx/src/CMakeFiles/cxx_shared.dir/atomic.cpp.o -c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/libcxx/src/atomic.cpp
06:48:56 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/libcxx/src/atomic.cpp:46:12: fatal error: 'os/os_sync_wait_on_address.h' file not found
06:48:56 46 | # include <os/os_sync_wait_on_address.h>
06:48:56 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
06:48:56 1 error generated.
```
This is the configuration the failing bots are running:
```
06:25:12 + sw_vers
06:25:12 ProductName: macOS
06:25:12 ProductVersion: 14.1
06:25:12 BuildVersion: 23B74
06:25:12 + xcodebuild -version
06:25:12 Xcode 15.2
06:25:12 Build version 15C5500c
```
The Intel bots are building fine though. Probably because they're on a
newer OS where the headers are available?
```
10:03:35 + sw_vers
10:03:35 ProductName: macOS
10:03:35 ProductVersion: 15.1.1
10:03:35 BuildVersion: 24B91
10:03:35 + xcodebuild -version
10:03:39 Xcode 16.2
10:03:39 Build version 16C5031c
10:03:39 + cmake --version
10:03:39 cmake version 3.30.2
```
|
|
At the moment, we use the os internal functions `__ulock_wait`. This
patch updates the code on macOS to use the public API
`os_sync_wait_on_address`.
Fixes #146142
|
|
```
----------------------------------------------
Benchmark old new
--------------------------- ------------------
BM_tolower_char<char> 1.64 ns 1.41 ns
BM_tolower_char<wchar_t> 1.64 ns 1.41 ns
BM_tolower_string<char> 32.4 ns 12.8 ns
BM_tolower_string<wchar_t> 32.9 ns 15.1 ns
BM_toupper_char<char> 1.63 ns 1.64 ns
BM_toupper_char<wchar_t> 1.63 ns 1.41 ns
BM_toupper_string<char> 32.2 ns 12.7 ns
BM_toupper_string<wchar_t> 33.0 ns 15.1 ns
```
|
|
This generalizes the support added in #99287 renaming the option to
RUNTIMES_USE_LIBC and integrating the module into libc++abi and
libunwind as well.
|
|
Fixes #109290
See the GH issue for the details. In conclusion, we have two issues in
the `atomic<T>::wait` when `T` does not match our `contention_t`:
- We don't have a total single order which can leads to missed
notification based on the Herd7 simulation on relaxed architectural like
PowerPC
- We assumed the platform wait (`futex_wait`/`__ulock_wait`) has seq_cst
barrier internally but there is no such guarantee
|
|
calls" (#144615)
Reverts llvm/llvm-project#143573
|
|
This newline was originally added in https://reviews.llvm.org/D142184
but I think updating `__libcpp_verbose_abort` to add newline instead is
more consistent, and works for other callers of `_LIBCPP_VERBOSE_ABORT`.
The `_LIBCPP_ASSERTION_HANDLER` calls through to either
`_LIBCPP_VERBOSE_ABORT` macro or the `__builtin_verbose_trap`. From what
I can tell neither of these function expect a trailing newline (at least
none of the usage of `_LIBCPP_VERBOSE_ABORT` or `__builtin_verbose_trap`
that I can find include a trailing newline except `_LIBCPP_ASSERTION_HANDLER`).
I noticed this discrepancy when working on
https://github.com/emscripten-core/emscripten/pull/24543
|
|
|
|
|
|
|
|
According to https://developer.apple.com/support/xcode/ the removed
annotations can't fire anymore, since the targets they would fire for
aren't supported anymore.
|
|
The parameter passed to __has_include has to be quoted by `<>` or `"`,
not both.
|
|
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756)
This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521.
Unfortunately, this use of hidden visibility attributes causes
user-defined specializations of standard-library types to also be marked
hidden by default, which is incorrect. See discussion thread on #131156.
...and also reverts the follow-up commits:
Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)"
This reverts commit 3e4c9dc299c35155934688184319d391b298fff7.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
|
|
It turns out that we're about to revert the patches that added these
annotations in the first place. I was too hasty to land this.
This reverts commit 56594710c7ffdaf82e07b1ff63f01226c117b2ce.
|
|
We get an error "cannot add 'abi_tag' attribute in a redeclaration"
because functions like `__dispatch_apply` are first declared without an
ABI tag due to `_LIBCPP_BEGIN_EXPLICIT_ABI_ANNOTATIONS` inside the
header, and then redeclared with an ABI tag in the .cpp file.
|
|
This doesn't show up in the CI, since we don't have abilists for
windows. I'm also not sure whether we want them, so I don't think we can
easily test this change.
|
|
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)
This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`,
which allow us to have implicit annotations for most functions, and just
where it's not "hide_from_abi everything" we add explicit annotations.
This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most
functions in libc++.
|
|
(#140121)
|
|
This adds a new test to run clang-tidy on the `src/` directory and
temporarily disables and clang-tidy checks that currently fail. They
will be enabled in follow-up patches.
|
|
|
|
Adds missing includes that were detected when I tried to build libc++ as
a module.
Working towards #127012
|
|
(#133876)
We plan to replace the existing mechanism for overriding detection with
one that doesn't require the use of a special section as an alternative
to llvm/llvm-project#120805 which had other downsides.
This change is a pure refactoring that lays the foundation for a
subsequent change that will introduce the new detection mechanism.
|
|
instead of ABI (#127697)
We're currently adding `bad_function_call::what()` behind an ABI flag,
even though adding it is not an ABI break and can be handled through
availability.
|
|
This patch moves the functions common between our two extern template
lists into a common list and avoids some unnecessary _Uglification. This
makes the code a lot nicer to read and makes the differences between the
two lists obvious.
|
|
This makes __libcpp_verbose_abort unconditionally noexcept. This was
planned for the upcomming release.
|
|
We have `[[fallthrough]]` available in all standards modes, so we can
just inline it like other stanard attributes we use.
|
|
This has multiple benefits:
- There is a single instance of our hash function, reducing object file
size
- The hash implementation isn't instantiated in every TU anymore,
reducing compile times
- Behind an ABI configuration macro it would be possible to salt the
hash
|
|
This is technically not necessary in most cases to prevent issues with ADL,
but let's be consistent. This allows us to remove the libcpp-qualify-declval
clang-tidy check, which is now enforced by the robust-against-adl clang-tidy check.
|
|
This was broken by #127339
|
|
On some (Linux) systems /etc/localtime is not a symlink to the time
zone, but contains a copy of the binary time zone file. In these case
there usually is a file named /etc/timezone which contains the text for
the current time zone name.
Instead of throwing when /etc/localtime does not exist or is not a
symlink use this fallback.
Fixes: #105634
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
(#126995)
Asan reports it after #124103.
It's know case of false positive for Asan.
https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco#false-positives
It's can be avoided with `constexpr` constructors.
In general order global constructors in different
modules is undefined. If global constructor uses
external global, they can be not constructed yet.
However, implementation may contain workaround for
that, or the state of non-constructed global can
be still valid.
Asan will still falsely report such cases, as it
has no machinery to detect correctness of such
cases.
We need to fix/workaround the issue in libc++, as
it will affect many libc++ with Asan users.
|
|
(#126219)
`__init(const value_type*, size_type, size_type)` is part of our ABI,
but we don't actually use the function anymore in the dylib. THis moves
the definition to the `src/` directory to make it clear that the code is
unused. This also allows us to remove it entirely in the unstable ABI.
|
|
The previous tested TZDB did not contain %z for the rule letters. The
usage of %z in TZDB 2024b revealed a bug in the implementation. The
patch fixes it and has been locally tested with TZDB 2024b.
Fixes #108957
|
|
```
----------------------------------------------------
Benchmark old new
----------------------------------------------------
BM_num_get<bool> 81.8 ns 79.6 ns
BM_num_get<long> 80.2 ns 75.4 ns
BM_num_get<long long> 81.5 ns 76.4 ns
BM_num_get<unsigned short> 82.5 ns 78.4 ns
BM_num_get<unsigned int> 82.8 ns 78.6 ns
BM_num_get<unsigned long> 81.2 ns 78.1 ns
BM_num_get<unsigned long long> 83.6 ns 76.7 ns
BM_num_get<float> 119 ns 120 ns
BM_num_get<double> 113 ns 109 ns
BM_num_get<long double> 115 ns 119 ns
BM_num_get<void*> 147 ns 139 ns
```
|
|
This refactors the standard stream implementation in multiple ways:
- The streams are now `stream_data` structs, which contain all the data
required for a stream
- The windows mangling is generated via a macro instead of having magic
strings for the different streams. (i.e. it's now only partially magic)
|
|
These symbols are never referenced directly outside the dylib, so we can
make them hidden instead. They are still in the dylib since can be
referenced through the `memory_resource*`, but dynamic linkers don't
have to do any work to deduplicate them.
|
|
|
|
929f159777bec47c80a3b302f190261d426e1c3b removed the use of
`__ANDROID_API__`
|
|
Reverts llvm/llvm-project#120805
This change while desirable has two issues we discovered:
- It is incompatible with `-funique-internal-linkage-names`, see
https://github.com/llvm/llvm-project/pull/120805#discussion_r1913709817
- It is incompatible with `-fvisibility-global-new-delete=force-hidden`,
see
https://github.com/llvm/llvm-project/issues/123224#issuecomment-2607963878
We were hoping to address both of these issues with
https://github.com/llvm/llvm-project/pull/122983, but that change has
other issues we haven't yet managed to resolve. For now, we have decided
to revert the change to avoid shipping a broken feature in LLVM 20, and
we plan to follow up with a new approach post branch.
|
|
This patch adds the following pieces to the locale base API:
- __setlocale (for std::setlocale)
- __lconv_t (for std::lconv)
- _LIBCPP_FOO_MASK and _LIBCPP_LC_ALL
This should be sufficient to implement all of the platform-agnostic
localization support in libc++ without relying directly on any public
API names from the C library. This makes it possible to port libc++ to
platforms that don't provide the usual locale APIs.
|
|
|
|
code (#122769)
That macro was present in the original implementation of the
synchronization library, but it was never defined and so it's
effectively unused.
|
|
This was missed in 43ba97e7079525a9686e15a6963508dfbd493f81 (#111821)
when reindenting after
917ada35cd937ad4104dff89c48398bd796ba6b7 (#80007).
|
|
std::shared_mutex (#107876)
Holding the associated lock while calling notify_* on a
condition_variable is generally considered a pessimization, as the
notified thread might "instantly" wake up, notice that it can't acquire
the lock, and then goes back to sleep.
|
|
Currently, places where we call __libcpp_allocate must drop type
information on the ground even when they actually have such information
available. That is unfortunate since some toolchains and system
allocators are able to provide improved security when they know what
type is being allocated.
This is the purpose of http://wg21.link/p2719, where we introduce a new
variant of `operator new` which takes a type in its interface. A
different but related issue is that `std::allocator` does not honor any
in-class `T::operator new` since it is specified to call the global
`::operator new` instead.
This patch closes the gap to make it trivial for implementations that
provide typed memory allocators to actually benefit from that
information in more contexts, and also makes libc++ forward-compatible
with future proposals that would fix the existing defects in
`std::allocator`. It also makes the internal allocation API higher level
by operating on objects instead of operating on bytes of memory.
Since this is a widely-used function and making this a template could
have an impact on debug info sizes, I tried minimizing the number of
templated layers by removing `__do_deallocate_handle_size`, which was
easy to replace with a macro (and IMO this leads to cleaner code).
|
