| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
(LLVM) now require GCC 5.1, so that's not a problem any more. Re-enable the assertion. Fixes PR#36863
llvm-svn: 362465
|
|
|
|
|
|
|
|
|
|
| |
ar doesn't produce the correct results when used for linking static
archives on Apple platforms, so instead use libtool -static which is
the official way to build static archives on those platforms.
Differential Revision: https://reviews.llvm.org/D62770
llvm-svn: 362311
|
|
|
|
|
|
| |
Thanks to Zoe for the (big, but simple) patch. NFC intended.
llvm-svn: 362252
|
|
|
|
| |
llvm-svn: 362115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
llvm-svn: 362113
|
|
|
|
|
|
| |
These two sources were omitted in r362055.
llvm-svn: 362061
|
|
|
|
|
|
|
|
|
|
|
| |
These seemed to have been used in the past but were since removed
by the add_compile_flags_if_supported functions that combine these
these checks and adding the flag, but the original checks were never
removed.
Differential Revision: https://reviews.llvm.org/D62566
llvm-svn: 362058
|
|
|
|
|
|
|
| |
This is a follow up to r362055, we need -Wunknown-pragmas otherwise
the check is going to succeed it the pragma isn't supported.
llvm-svn: 362057
|
|
|
|
|
|
|
|
|
| |
This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.
llvm-svn: 362055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.
This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.
Differential Revision: https://reviews.llvm.org/D62090
llvm-svn: 362048
|
|
|
|
|
|
| |
It's incredibly annoying when trying to create diffs
llvm-svn: 361981
|
|
|
|
| |
llvm-svn: 361970
|
|
|
|
| |
llvm-svn: 361917
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
merged type info names.
Previously std::type_info always expected type info string to be unique.
But this isn't always the case. Like when -Bsymbolic is passed to the
linker or due to llvm.org/PR37398.
This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake
option which, when specified, overrides the default configuration for
the library.
The current defaults still assume unique names even though this isn't
strictly correct for ELF binaries. We should consider changing the
default in a follow up commit.
llvm-svn: 361913
|
|
|
|
| |
llvm-svn: 361894
|
|
|
|
|
|
| |
behavior. Reviewed as https://reviews.llvm.org/D61828. Thanks to Mark for the catch and the fix.
llvm-svn: 361887
|
|
|
|
| |
llvm-svn: 361594
|
|
|
|
| |
llvm-svn: 361593
|
|
|
|
| |
llvm-svn: 361574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature).
However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a.
Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55840
llvm-svn: 361572
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.
Reviewers: phosek, compnerd, smeenai, EricWF
Reviewed By: compnerd
Subscribers: EricWF, christof, libcxx-commits, mgorny, llvm-commits
Tags: #llvm, #libc
Differential Revision: https://reviews.llvm.org/D62155
llvm-svn: 361513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests assume that iteration through an unordered multiset elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return
elements exactly from a set of valid values and without repetition,
but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56500
llvm-svn: 361494
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
include/c++
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/$target/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch is a continuation of D54838 and introduces checks verifying that
any iteration will return elements exactly from a set of valid values
and without repetition, but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56498
llvm-svn: 361414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSVC CRT uses TLS storage to implement per-thread locales.
This storage gets freed during program termination, and if we attempt
to do any io operations (like flushing the std streams) after this occurs
the program may abort.
This patch is a speculative fix for that issue.
The fix tries forcing the initialization of the locale TLS before
initializing the std streams. This should mean that the TLS is freed
after we destroy the streams.
llvm-svn: 361348
|
|
|
|
|
|
| |
https://reviews.llvm.org/D61954
llvm-svn: 361201
|
|
|
|
| |
llvm-svn: 361075
|
|
|
|
|
|
|
|
| |
The `using namespace std;` opens us up to ambiguity
when any of the std:: names are also present in the global namespace.
Instead we should properly qualify names we use from std::.
llvm-svn: 361074
|
|
|
|
| |
llvm-svn: 360911
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use std::nextafter() instead of std::nexttoward() in midpoint tests.
In the context of this test, this should not cause any difference.
Since nexttowardl() is not implemented on NetBSD 8, the latter function
combined with 'long double' type caused test failure. nextafterl() does
not have this problem.
Differential Revision: https://reviews.llvm.org/D61748
llvm-svn: 360673
|
|
|
|
|
|
| |
Patch by Ben Craig.
llvm-svn: 360590
|
|
|
|
|
|
| |
https://reviews.llvm.org/D61829 Thanks to Zoe for the patch.
llvm-svn: 360586
|
|
|
|
| |
llvm-svn: 360306
|
|
|
|
| |
llvm-svn: 360167
|
|
|
|
|
|
|
| |
It's a remnant from an earlier version of the lerp change
and is unneeded.
llvm-svn: 360098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61571
llvm-svn: 360003
|
|
|
|
|
|
| |
See discussion on https://reviews.llvm.org/D48292
llvm-svn: 359907
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocates with ::new
Drive-by:
* Fix potential race between check and update of `throw_one` in `operator new`
* Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer
* Specifically catch the expected `bad_alloc` in `main` instead of `...`
Differential Revision: https://reviews.llvm.org/D50860
llvm-svn: 359827
|
|
|
|
|
|
|
|
| |
Instead of manually linking against libm/librt/libpthread, we should be
linking against libSystem on Apple platforms, and only that. libm and
libpthread are symlinks to libSystem anyway.
llvm-svn: 359808
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces support for building libc++. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D61143
llvm-svn: 359806
|
|
|
|
|
|
|
| |
REMOVE_ITEM fails if CMAKE_REQUIRED_LIBRARIES is empty on some
versions of cmake.
llvm-svn: 359755
|
|
|
|
|
|
|
|
| |
Linux is failing even though the test runner does report this locale
is available, but the test still isn't expected to work on platforms
without the locale (like Android).
llvm-svn: 359726
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds explicit support for the WASI platform to libcxx.
WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.
Differential Revision: https://reviews.llvm.org/D61336
Reviewers: sbc100, ldionne
llvm-svn: 359703
|
|
|
|
|
|
| |
debug_level set. NFC
llvm-svn: 359672
|
|
|
|
|
|
|
|
|
| |
This addresses the longstanding FIXME and makes libc++ build more
similar to other runtimes.
Differential Revision: https://reviews.llvm.org/D61275
llvm-svn: 359656
|
|
|
|
|
|
| |
_LIBCPP_DEBUG was set.
llvm-svn: 359642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current implementation of aligned storage was written before we had `alignas`, so it used a list of builtin types to force the alignment. But this doesn't work overaligned requests.
This patch adds a fallback case supporting over-alignment. It only affects case that were previously ill-formed.
Reviewers: rsmith, ldionne, dlj, mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D61301
llvm-svn: 359596
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 359526
|
|
|
|
| |
llvm-svn: 359525
|