Stack overflow on invalid. While collapsing references, we were skipping over a
cycle check in ForwardTemplateReference leading to a stack overflow. This commit
fixes the problem by duplicating the cycle check in ReferenceType.
llvm-svn: 338190
Summary:
rL337867 introduced two new cmake_dependent_option options:
- LIBCXXABI_INSTALL_STATIC_LIBRARY
- LIBCXXABI_INSTALL_SHARED_LIBRARY
They depend on LIBCXXABI_ENABLE_STATIC and LIBCXXABI_ENABLE_SHARED
and so therefore need to (it seems) come after the declaration of
these two options.
Subscribers: mgorny, aheejin, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D49825
llvm-svn: 337982
Currently it's only possible to control whether shared or static library
build of libc++, libc++abi and libunwind is enabled or disabled and
whether to install everything we've built or not. However, it'd be
useful to have more fine grained control, e.g. when static libraries are
merged together into libc++.a we don't need to install libc++abi.a and
libunwind.a. This change adds this option.
Differential Revision: https://reviews.llvm.org/D49573
llvm-svn: 337867
We really should set *status to memory_alloc_failure, but we need to refactor
the demangler a bit to properly propagate the failure up the stack. Until then,
its better to explicitly terminate then rely on a null dereference crash.
rdar://31240372
llvm-svn: 337759
This allows handling SEH based exceptions, with unwind functions
provided by libgcc.
Differential Revision: https://reviews.llvm.org/D49638
llvm-svn: 337754
Currently it's possible to select whether to statically link unwinder
or the C++ ABI library, but this option applies to both the shared
and static library. However, in some scenarios it may be desirable to
only statically link unwinder and C++ ABI library into static C++
library since for shared C++ library we can rely on dynamic linking
and linker scripts. This change enables selectively enabling or
disabling statically linking only to shared or static library.
Differential Revision: https://reviews.llvm.org/D49502
llvm-svn: 337668
ItaniumDemangle had a small NFC refactor to make some of its
code reusable by the newly added Microsoft demangler. To keep
the libcxxabi demangler as close as possible to the master copy
this refactor is being merged over.
Differential Revision: https://reviews.llvm.org/D49575
llvm-svn: 337582
Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal
variable used by the runtimes build from individual runtimes, instead
set per-runtime librarhy directory suffix variable which is necessary
for the sanitized runtimes build to install libraries into correct
location.
Differential Revision: https://reviews.llvm.org/D49121
llvm-svn: 336713
The alignment specified by a constant for the field
`BumpPointerAllocator::InitialBuffer` exceeded the alignment
guaranteed by `malloc` and `new` on Windows. This change set
the alignment value to that of `long double`, which is defined
by the used platform.
It fixes https://bugs.llvm.org/show_bug.cgi?id=37944.
Differential Revision: https://reviews.llvm.org/D48889
llvm-svn: 336312
vector is a generic C++ header, whereas __config is libc++-specific, so
we can look for it instead to guarantee we're finding a libc++
installation. This was suggested by Eric in https://reviews.llvm.org/D48694.
This is less important now that we're limiting the header search to the
specified directories (which definitely shouldn't have any other C++
library's headers anyway), but it shouldn't hurt either. There's a
chance some other library could also be providing a __config header, so
there's still a trade-off there. It would be ideal if we could check for
the presence of both __config and vector in the same directory, but
there doesn't seem to be any easy way to do that in CMake.
llvm-svn: 336034
Right now, when libc++abi is locating libc++ headers, it specifies
several search locations, but it also doesn't prevent CMake from looking
for those headers in system directories. I don't know if this was
intentional or an oversight, but it has several issues:
* We're looking specifically for the vector header, which could just as
easily be found in a libstdc++ (or other C++ library) installation.
* No system I know of places their C++ headers directly in system
include directories (they're always under a C++ subdirectory), so the
system search will never succeed.
* find_path searches system paths before the user-specified PATHS, so
if some system does happen to have C++ headers in its system include
directories, those headers will be preferred, which doesn't seem
desirable.
It makes sense to me to limit this header search to the explicitly
specified paths (using NO_DEFAULT_PATH, as is done for the other
find_path call in this file), but I'm putting it up for review in case
there's some use case I'm not thinking of.
Differential Revision: https://reviews.llvm.org/D48694
llvm-svn: 336032
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48355
llvm-svn: 335171
Patch by Ryan Prichard
If the destination type does not derive from the static type, we can skip
the search_above_dst call, but we still need to run the
!does_dst_type_point_to_our_static_type block of code. That block of code
will increment info->number_to_dst_ptr to 2, and because dest isn't derived
from static, the cast will ultimately fail.
Fixes PR33439
Reviewed as https://reviews.llvm.org/D36447
llvm-svn: 332767
This adds the test which was mistakenly not committed in r332763.
Patch by Ryan Prichard
Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.
Fixes PR33425 and PR33487
Reviewed as https://reviews.llvm.org/D36446
llvm-svn: 332764
Patch by Ryan Prichard
Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.
Fixes PR33425 and PR33487
Reviewed as https://reviews.llvm.org/D36446
llvm-svn: 332763
This is a follow-up change to r331150. The CL moved the macro from individual
file to build file, but the macro is missed in a test config file.
https://reviews.llvm.org/D46385
Patch from Taiju Tsuiki <tzik@chromium.org>!
llvm-svn: 331450
_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is currently used to
bring back std::unexpected, which is removed in C++17, but still needed
for libc++abi for backward compatibility.
This macro used to define in cxa_exception.cpp only, but actually
needed for all sources that touches exceptions.
So, a build-system-level macro is better fit to define this macro.
https://reviews.llvm.org/D46056
Patch from Taiju Tsuiku <tzik@chromium.org>!
llvm-svn: 331150
This is basically part 2 of r313694.
It's a little unfortunate that I had to copy-paste atomic_support.h,
but I don't really see any alternative.
The refstring.h changes are the same as the libcxx changes in r313694.
llvm-svn: 330162
Summary:
exception_header->exceptionDestructor is a void(*)(void*) function
pointer; however, it can point to destructors like std::
exception::~exception that don't match that type signature.
Reviewers: pcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: kcc, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D45455
llvm-svn: 329629
Strictly in a conversion operator's type, a <template-param> refers to a
<template-arg> that is further ahead in the mangled name. Instead of
doing a second parse to resolve these, introduce a
ForwardTemplateReference Node and back-patch the referenced
<template-arg> when we're in the right context.
This is also a correctness fix, previously we would only do a second
parse if the <template-param> was out of bounds in the current set of
<template-args>. This lead to misdemangles (gasp!) when the conversion
operator was a member of a templated struct, for instance.
llvm-svn: 328464
Rather than eagerly propagating up parameter pack sizes in Node ctors,
find the parameter pack size during printing. This is being done to
support back-patching forward referencing <template-param>s.
llvm-svn: 328463
Hans Wennborg