LLVM dropped support for Visual Studio versions older than 2015 quite
some time ago, so I consider it safe to drop libc++'s support for older
CRTs. The CRT in Visual Studio 2015 provides a lot of previously missing
functions, so targeting it requires less special casing.
Differential Revision: https://reviews.llvm.org/D31798
llvm-svn: 299743
These tests were unconditionally asserting that optional and unique_ptr declare throwing hashes, but MSVC++ implements conditional noexcept forwarding that of the underlying hash function. As a result we were failing these tests but there's nothing forbidding strengthening noexcept in that way.
Changed the ASSERT_NOT_NOEXCEPT asserts to use types which themselves have non-noexcept hash functions.
llvm-svn: 299734
We're using -nodefaultlibs to avoid the dependency on C++ library
when using check_cxx_compiler_flag, and as such we cannot use
check_cxx_compiler_flag to check the availability of -nodefaultlibs
itself.
llvm-svn: 299711
Can be used as such:
$ python /path/to/lit.py -sv /path/to/llvm/build/projects/libcxx/test/ \
--param=use_system_cxx_lib=true \
--param=executor='SSHExecutor("remote.domain", "username")'
llvm-svn: 299607
When compiler-rt is requested, we should attempt to link compiler-rt
builtins library rather than gcc_s.
Differential Revision: https://reviews.llvm.org/D31617
llvm-svn: 299599
Method specializations don't get exported even if there's an exported
extern template instantiation on Windows. Explicitly mark the methods
for export. They're already exported on Linux and Darwin, so there's no
ABI change on those platforms.
llvm-svn: 299348
This is effectively a partial revert of r278356, which started inlining
basic_string::__init. Even if we want to help the compiler along with
an inlinehint, we shouldn't hamstring it by forcing it to inline all the
time.
Libc++ uses always_inline widely as a limit-the-ABI-hack, but since
__init is already on the dylib boundary, it makes no sense here and just
harms the debugging experience at -O0.
rdar://problem/31013102
llvm-svn: 299290
r145698 introduced _LIBCPP_HAS_NO_STRONG_ENUMS by copy-pasting the
__has_feature check from objc_arc_weak/_LIBCPP_HAS_OBJC_ARC_WEAK, and
accidentally started defining _LIBCPP_HAS_NO_STRONG_ENUMS whenever
__has_feature(objc_arc_weak). This is totally bogus, and means that
Libc++ thinks Objective-C++ compilations with -fobjc-arc don't have
strong enums.
Delete the accidental line.
I thought about adding a test, but it would be entirely duplicative of
the patch (if has-feature strong enums, check that has-no-strong-enums
is not defined).
llvm-svn: 299236
Summary:
mingw64 has lots of default libs that libc++ and its test programs
should link against.
With this patch, cmake now runs successfully with GCC on Windows.
Reviewers: mati865, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D31518
llvm-svn: 299144
Both libc++ and libc++abi export a weak definition of operator
new/delete. On Darwin, this can often cause dirty __DATA in the
shared cache when having to switch from one to the other. Instead,
libc++ should reexport libc++abi's implementation of these symbols.
Patch by: Ted Kremenek <kremenek@apple.com>
Differential Revision: https://reviews.llvm.org/D30765
llvm-svn: 299054
As we're trying to setup testing / bots for all shipping version of libc++
on macOS/iOS, we'll need to be able to pass a path to where to find the
dylib for each previous version of the OS.
Differential Revision: https://reviews.llvm.org/D31486
llvm-svn: 299053
Summary:
bad_function_call is currently an empty class, so any object files using
that class will end up with their own copy of its typeinfo, typeinfo
name and vtable, leading to unnecessary duplication that has to be
resolved by the dynamic linker. Instead, give bad_function_call a key
function and put a definition for that key function in libc++ itself, to
centralize the typeinfo and vtable.
This is consistent with the behavior for other exception classes. The
key functions are defined in libc++ rather than libc++abi since the
class is defined in the libc++ versioning namespace, so ABI
compatibility with libstdc++ is not a concern.
Guard this change behind an ABI macro, since it isn't backwards
compatible (i.e., clients built against the new libc++ headers wouldn't
be able to run against an older libc++ library).
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D27387
llvm-svn: 298937
Summary:
By manipulating a local variable in the loop, when the loop can
be optimized away (due to no non-trivial destructors), this lets
it be fully optimized away and we modify the __end_ separately.
This results in a substantial improvement in the generated code.
Prior to this change, this would be generated (on x86_64):
movq (%rdi), %rdx
movq 8(%rdi), %rcx
cmpq %rdx, %rcx
je LBB2_2
leaq -12(%rcx), %rax
subq %rdx, %rax
movabsq $-6148914691236517205, %rdx ## imm = 0xAAAAAAAAAAAAAAAB
mulq %rdx
shrq $3, %rdx
notq %rdx
leaq (%rdx,%rdx,2), %rax
leaq (%rcx,%rax,4), %rax
movq %rax, 8(%rdi)
And after:
movq (%rdi), %rax
movq %rax, 8(%rdi)
This brings this in line with what other implementations do.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25241
llvm-svn: 298601
