Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .
Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.
This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .
Notes:
* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)
Differential Revision: https://reviews.llvm.org/D70631
Microsoft would like to contribute its implementation of floating-point to_chars to libc++. This uses the impossibly fast Ryu and Ryu Printf algorithms invented by Ulf Adams at Google. Upstream repos: https://github.com/microsoft/STL and https://github.com/ulfjack/ryu .
Licensing notes: MSVC's STL is available under the Apache License v2.0 with LLVM Exception, intentionally chosen to match libc++. We've used Ryu under the Boost Software License.
This patch contains minor changes from Jorg Brown at Google, to adapt the code to libc++. He verified that it works in Google's Linux-based environment, but then I applied more changes on top of his, so any compiler errors are my fault. (I haven't tried to build and test libc++ yet.) Please tell me if we need to do anything else in order to follow https://llvm.org/docs/DeveloperPolicy.html#attribution-of-changes .
Notes:
* libc++'s integer charconv is unchanged (except for a small refactoring). MSVC's integer charconv hasn't been tuned for performance yet, so you're not missing anything.
* Floating-point from_chars isn't part of this patch because Jorg found that MSVC's implementation (derived from our CRT's strtod) was slower than Abseil's. If you're unable to use Abseil or another implementation due to licensing or technical considerations, Microsoft would be delighted if you used MSVC's from_chars (and you can just take it, or ask us to provide a patch like this). Ulf is also working on a novel algorithm for from_chars.
* This assumes that float is IEEE 32-bit, double is IEEE 64-bit, and long double is also IEEE 64-bit.
* I have added MSVC's charconv tests (the whole thing: integer/floating from_chars/to_chars), but haven't adapted them to libcxx's harness at all. (These tests will be available in the microsoft/STL repo soon.)
* Jorg added int128 codepaths. These were originally present in upstream Ryu, and I removed them from microsoft/STL purely for performance reasons (MSVC doesn't support int128; Clang on Windows does, but I found that x64 intrinsics were slightly faster).
* The implementation is split into 3 headers. In MSVC's STL, charconv contains only Microsoft-written code. xcharconv_ryu.h contains code derived from Ryu (with significant modifications and additions). xcharconv_ryu_tables.h contains Ryu's large lookup tables (they were sufficiently large to make editing inconvenient, hence the separate file). The xmeow.h convention is MSVC's for internal headers; you may wish to rename them.
* You should consider separately compiling the lookup tables (see https://github.com/microsoft/STL/issues/172 ) for compiler throughput and reduced object file size.
* See https://github.com/StephanTLavavej/llvm-project/commits/charconv for fine-grained history. (If necessary, I can perform some rebase surgery to show you what Jorg changed relative to the microsoft/STL repo; currently that's all fused into the first commit.)
Differential Revision: https://reviews.llvm.org/D70631
The aim of this patch is to resolve the missing `table_size` symbol (see reduced test case). That const variable is declared and defined in //libcxx/include/locale//; however, the test case suggests that the symbol is missing. This is due to a C++ pitfall (highlighted [[ https://quuxplusone.github.io/blog/2020/09/19/value-or-pitfall/ | here ]]). In summary, assigning the reference of `table_size` doesn't enforce the const-ness and expects to find `table_size` in the DLL. The fix is to use `constexpr` or have an out-of-line definition in the src (for consistency).
Differential Revision: https://reviews.llvm.org/D110647
However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.
Also separate preprocessor definitions for whether to use a key function
and whether to use a `bad_function_call`-specific `what` message
(`what` message is mandated by [LWG2233](http://wg21.link/LWG2233)).
Differential Revision: https://reviews.llvm.org/D92397
However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.
Differential Revision: https://reviews.llvm.org/D92397
Currently the member functions std::allocator<T>::allocate,
std::experimental::pmr::polymorphic_allocator::allocate and
std::resource_adaptor<T>::do_allocate throw an exception of type
std::length_error when the requested size exceeds the maximum size.
According to the C++ standard ([allocator.members]/4,
[mem.poly.allocator.mem]/1), std::allocator<T>::allocate and
std::pmr::polymorphic_allocator::allocate must throw a
std::bad_array_new_length exception in this case.
The patch fixes the issue with std::allocator<T>::allocate and changes
the type the exception thrown by
std::experimental::pmr::resource_adaptor<T>::do_allocate to
std::bad_array_new_length as well for consistency.
The patch resolves LWG 3237, LWG 3038 and LWG 3190.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D110846
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.
This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.
Differential Revision: https://reviews.llvm.org/D106009
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety in actual code because we do not implement the
underlying garbage collection support. In fact, P2186 even proposes
removing these facilities entirely from a future C++ version. As such,
I think it's entirely fine to get rid of complex workarounds whose goals
were to avoid breaking the ABI back in 2017.
I'm putting this up both to get reviews and to discuss this proposal for
a breaking change. I think we should be comfortable with making these
tiny breaks if we are confident they won't hurt anyone, which I'm fairly
confident is the case here.
Differential Revision: https://reviews.llvm.org/D100410
This is the first step at implementing <format>. It adds the <format> header
and implements the `format_error`. class.
Implemnts parts of:
-P0645 Text Formatting
Reviewed By: ldionne, #libc, miscco, curdeius
Differential Revision: https://reviews.llvm.org/D92214
By encoding ABI-affecting properties in the name of the ABI list, it
makes it clear when an ABI list test should or should not be available,
and what results we should expect.
Note that we clearly don't encode all ABI-affecting parameters in the
name right now -- I just ported over what we supported in the code that
was there previously. As we encounter configurations that we wish to
support but produce different ABI lists, we can add those to the ABI
identifier and start supporting them.
This commit also starts checking the ABI list in the CI jobs that run
a supported configuration. Eventually, all configurations should have
a generated ABI list and the test should even run implicitly as part of
the Lit test suite.
Differential Revision: https://reviews.llvm.org/D92194
We don't actually update the ABI lists at every release -- it's too much
work, since we'd technically have to do it even for minor releases.
Furthermore, I don't think anybody uses those (I certainly don't rely
on them for anything).
Instead, it is better to rely on the ABI list changelog and the canonical
ABI list that we always keep up to date. If one wants to know what symbols
were shipped in a specific release, that can be discovered easily using
Git, which is a superior tool than keeping textual copies of old versions.
The `posix_memalign@GLIBC_2.2.5` symbol can't have been added by r284206,
because it doesn't show up in the corresponding ABI list. It's also not
defined in libc++, so that wouldn't make sense. It must have made it into
that comment by mistake.
This commit adds new explicit instantiations for some classes in <iostream>
in the library. This is done after noticing that many programs that use
streams end up containing weak definitions of these classes, which has a
negative impact on both code size and load times (due to the need to
resolve weak symbols at load time). Note that we are just adding the
additional explicit instantiations for the `char` specializations, since
the `wchar_t` specializations are not used as often, and as a result there
wouldn't be a clear benefit.
This change is not an ABI break, since we are just adding additional
symbols.
Differential Revision: https://reviews.llvm.org/D90677
Instead of having to remember the command-line to use every time, this
commit adds a CMake target to generate the ABI list in the current
configuration, if it is supported.
As a fly-by change, remove scripts that are now unused (sym_match.py
and sym_extract.py).
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).
My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.
Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.
On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.
On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.
Differential Revision: https://reviews.llvm.org/D68269
This reverts commit c7d4aa711a. I am still investigating the issue,
but it looks like that commit has an interaction with ld64 that causes
new/delete weak re-exports not to work properly anymore. This is weird
because this commit did not touch the exports of new/delete -- I am
still investigating.
Instead of managing two copies of the symbol lists, reuse the same list
in libc++abi and libc++.
Differential Revision: https://reviews.llvm.org/D88623
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
- Avoid using C++11-and-later features in <atomic>:
Historically, we've supported <atomic> in C++03, so we can't use C++11
features in that header. This is something we really need to change,
since our implementation of <atomic> is starting to accumulate technical
debt because of that.
- Mark a test as unsupported on single threaded systems
- Add missing symbols to the Linux ABI list
- Add the new symbols to the ABI list on Darwin
- Add XFAIL markup to the tests that require dylib support on older platforms
- Add availability markup for back-deployment
This addresses the longstanding FIXME and makes libc++ build more
similar to other runtimes.
Differential Revision: https://reviews.llvm.org/D61275
llvm-svn: 359656
Summary:
Instead of populating the global LIBCXX_LIBRARIES, we use the link-time
dependency management built into CMake to propagate link flags. This
leads to a cleaner and easier-to-follow build.
Reviewers: phosek, smeenai, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60969
llvm-svn: 359571
libc++ ABI v1 provides three valarray symbols as part of the shared library:
valarray<size_t>::valarray(size_t)
valarray<size_t>::~valarray()
valarray<size_t>::resize(size_t, size_t)
The first two of these are intended to be removed in V2 of the ABI: they're
attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention
is that these symbols from the library are not used even when building using
the V1 ABI. However, there are explicit instantiation declarations for all
three symbols in the header, which are not correct as we do not intend to find
an instantiation of these functions that is provided elsewhere.
(A recent change to clang to properly diagnose explicit instantiation
declarations of internal linkage functions -- required by [temp.explicit]p13 --
had to be rolled back because it diagnosed these explicit instantiations.)
Remove the explicit instantiation declarations, and remove the explicit
instantiation definitions for V2 of the libc++ ABI onwards.
llvm-svn: 359243
This enables the use of this script from other build systems like
GN which don't support post-build actions as well as for static
archives.
Differential Revision: https://reviews.llvm.org/D60309
llvm-svn: 358915
Summary:
Ensure we re-export __cxa_throw_bad_array_new_length and
__cxa_uncaught_exceptions from libc++, since they are now
provided by libc++abi.
Doing this allows us to stop linking explicitly against libc++abi in
the libc++abi tests, since libc++ re-exports all the necessary symbols.
However, there is one caveat to that. We don't want libc++ to re-export
__cxa_uncaught_exception (the singular form), since it's only provided
for backwards compatibility. Hence, for the single test where we check
this backwards compatibility, we explicitly link against libc++abi.
PR27405
PR22654
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60424
llvm-svn: 358690
Some linker libraries are only needed for shared libc++, some only
for static libc++, combining these together in LIBCXX_LIBRARIES and
LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies.
This changes splits those up into LIBCXX_SHARED_LIBRARIES and
LIBCXX_STATIC_LIBRARIES matching what libc++abi already does.
Differential Revision: https://reviews.llvm.org/D57872
llvm-svn: 358614
In this case, CMake doesn't know about the c++abi target within the
same CMake run.
This reverts this aspect back to how it was before SVN r357811.
Differential Revision: https://reviews.llvm.org/D60448
llvm-svn: 358009
CMake already specifies those, and we never actually want those to be
used. In fact, r357811 re-ordered those flags in a way that the
explicitly-provided install_name was overriding the CMake-provided
install_name (instead of the other way around). This caused the dylib
to be considered a system dylib, and hence the explicitly provided rpath
to be ignored. This, in turn, caused some unit tests to start linking
against the system libc++.dylib instead of the freshly-built one.
Specifically, the unit tests that started linking against the system
dylib are those that didn't specify a DYLD_LIBRARY_PATH, such as
last_write_time.sh.cpp.
llvm-svn: 357946
The refactoring in r357811 made it so that we didn't add the ABI library
to the list of LIBCXX_LIBRARIES. As a result, benchmarks didn't link to
the ABI library and were missing symbols. This broke the build bots.
As a drive-by fix, we also provide the SHARED ABI library to the linker
script instead of the STATIC ABI library.
This couldn't be discovered on Apple platforms because libc++.dylib
re-exports libc++abi.dylib symbols there.
llvm-svn: 357818
Summary:
There's a lot of CMake logic that's only relevant to the shared library,
yet it was using a code path and setting variables that impact both the
shared and the static libraries. This patch moves this logic so that it
clearly only impacts the shared library.
Reviewers: phosek, smeenai, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60276
llvm-svn: 357811
Mark de Wever