This commit makes it clear that the typeinfo comparison implementation
is automatically selected by default, and that the CMake option only
overrides the value. This has been a source of confusion and bugs ever
since we've introduced complexity in that area, so I'm trying to simplify
it while still allowing for some control on the implementation.
Differential Revision: https://reviews.llvm.org/D91574
These functions are called directly from the public installed
headers, and thus need to be exported in DLL builds, just like
some other functions in the same header (e.g. snprintf_l).
This fixes e.g. test/std/localization/locale.categories/category.numeric/locale.num.get/facet.num.get.members/get_float.pass.cpp
in mingw configurations.
Differential Revision: https://reviews.llvm.org/D91328
These changes cause substantial binary size increases for non-opt builds.
For example, the visit.pass.cpp test grows from 20k to 420k.
Further work will be done to re-land this patch without the size increases,
but that work is proving too tricky to fix forward.
This patch fully reverts:
* 35d2269111
And it partially reverts:
* bb43a0cd4a
The latter of which added XFAIL's to new variant tests
because the new implementation needlessly makes non-throwing code
paths in variant invoke throwing code.
This means the reverted change also breaks source backwards compat
with code compiled on OS X targeting older system dylibs. There is no
need for this to be the case. We should fix it before recommitting.
Reviewed as:
https://reviews.llvm.org/D91662
Erroring out prevents the library from working with other file formats
(e.g. in embedded). Since that error does not guard us from doing something
incorrect, it seems fine to just remove it.
Also, enable them whenever we detect that gdb is available. Previously,
these tests would basically never run because they relied on a CMake
configuration option that defaulted to OFF.
Differential Revision: https://reviews.llvm.org/D91434
We don't need to do that on other Apple platforms, since they never
shipped libstdc++. I also added a comment extracted from the original
commit by Howard Hinnant (e115af2777).
Differential Revision: https://reviews.llvm.org/D91359
This patch adds a shim for missing time functions on z/OS, and adds a
layer of indirection to account for differences in the timespec struct
on different systems.
This was originally committed as 173b51169b and reverted in 777ca48c9f
because the original commit also checked-in unrelated changes.
Differential Revision: https://reviews.llvm.org/D87940
The unavailability of posix_memalign on z/OS forces us to define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION'. The use of posix_memalign is being used in libcxx/src/new.cpp.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D90178
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
This patch is one part of many steps required to build libc++ and libc++abi libraries on z/OS. This particular deals with time related functions and consists of the following 3 parts.
1) Initialization of :timeval within libc++ library need to be adjusted to work on z/OS.
The following is z/OS definition from time.h which includes additional aggregate member.
typedef signed int suseconds_t;
struct timeval {
time_t tv_sec;
char tv_usec_pad[4];
suseconds_t tv_usec;
};
In contracts the following is definition from time.h on Linux.
typedef long int __suseconds_t;
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
};
2) In addition, retrieving ::timespec within libc++ library needs to be adjusted to compensate the difference of some of the members of ::stat depending of the target host.
Here are the 2 members in conflict on z/OS extracted from stat.h.
struct stat {
...
time_t st_atime;
time_t st_mtime;
...
};
In contract here is Linux equivalent from stat.h.
struct stat
{
...
struct timespec st_atim;
struct timespec st_mtim;
...
};
3) On Linux both members are of type timespec whereas on z/OS an object of type timespec need to be constructed first before retrieving it within libc++ library.
The libc++ header file __threading_support calls nanosleep, which is not available on z/OS.
The equivalent functionality will be implemented by using both sleep() and usleep().
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D87940
This was implemented in 410b650e674496e61506fa88f3026759b8759d0f:
"Implement P0340R3: Make 'underlying_type' SFINAE-friendly. Reviewed as https://reviews.llvm.org/D63574
llvm-svn: 364094"
Some changes were made to the libc++abi new/delete definitions, but
they were not copied back to the libc++ definition. It sucks that we
have this duplication, but for now at least let's keep them in sync.
This is consistent with what's done in locale.cpp, and it ensures that
we get the default rune table whenever _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE
is defined, regardless of the actual platform.
Differential Revision: https://reviews.llvm.org/D91074
This patch changes how linear_congruential_engine picks its randomization
algorithm. It adds two restrictions, `_OverflowOK` and `_SchrageOK`.
`_OverflowOK` means that m is a power of two so using the classic
`(a * x + c) % m` will create a meaningless overflow. The second checks
that Schrage's algorithm will produce results that are in bounds of min
and max. This patch fixes https://llvm.org/PR27839.
Differential Revision: D65041
The aim of this patch is to enable POSIX _l functions for z/OS. In particular, the functions are provided with libc++ and this patch resorts to the fallback functions. Nonetheless, the functions are being added so the implementation of the ctype<> member functions can call them. The following changes were needed to allow for a successful build when using the libc++ library for z/OS.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D90319
Emscripten doesn't use this file (at least not anymore), it uses
exception_libcxxabi.ipp since _LIBCPPABI_VERSION is defined.
Differential Revision: https://reviews.llvm.org/D91041
When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).
llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.
This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.
This is a revert of the following commits:
libunwind: 3a667b9bd8
libc++abi: 4877063e19
libc++: 88434fe05f
Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.
Differential Revision: https://reviews.llvm.org/D91099
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.
At the same time, also fix some tests that were failing when back
deploying.
Differential Revision: https://reviews.llvm.org/D90869
Remove Phabricator, which isn't needed anymore since we don't report
the job results ourselves. Also, install python3-sphinx instead of
sphinx-doc, since the latter doesn't provide the sphinx-build binary.
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.
For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.
In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.
Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).
Differential Revision: https://reviews.llvm.org/D90843
This undefined behavior was found by applying Lénárd Szolnoki's proposal
to disable implicit conversion of default_delete<D> to default_delete<B>.
The offending part of the test is circa line 243.
The wording that makes it undefined behavior is http://eel.is/c++draft/expr.delete#3 .
Differential Revision: https://reviews.llvm.org/D90536
`mftb` and `mftbl` are equivalent, there is no need to have two names for doing the same thing, rename `mftbl` to only have `mftb`.
Differential Revision: https://reviews.llvm.org/D89506
Those are part of the library, and shipping them just adds a tiny bit of
size to the distribution. This was originally added in b422ecc7de to
make it possible to match the Makefile build, which doesn't exist anymore.
The upside is build system simplification.
Louis Dionne