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
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
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
This commit cleans up the expression parser, using a new style:
- parse* functions now return Node pointers.
- The mangled name is now held in Db and accessed with look() and consume()
- LLVM coding style
This style is meant to avoid the 2 most common types of bugs in the
old demanger, namely misusing the Names stack (ie, calling back() on
empty) and going out of bounds on the mangled name. I also think it
makes the demangler a lot cleaner.
Differential revision: https://reviews.llvm.org/D41887
llvm-svn: 324111
This commit changes how variadic templates are represented in the
demangler, in order to fix some longstanding bugs. Now instead of
expanding variadic templates during parsing, the expansion is done
during printing by reusing the unexpanded AST. This allows the
demangler to handle cases where multiple packs contribute to a single
production, and correctly handle "Dp" and "sp" productions, which
corrispond to pack expansions in type and expression contexts.
Differential revision: https://reviews.llvm.org/D41885
llvm-svn: 323906
This patch updates libc++abi's HandleOutOfTreeLLVM.cmake to match
libc++'s -- and more importantly, to fix a bug where llvm-lit wasn't
found/created when libc++abi was built out-of-tree. This prevented
the test suite from running.
llvm-svn: 322768
The demangler now demangles by producing an AST, then traverses that
AST to produce a demangled name. This is done for performance reasons,
now the demangler doesn't manuiplate std::strings, which hurt
performance and caused string operations to be inlined into the
parser, leading to large code size and stack usage.
Differential revision: https://reviews.llvm.org/D35159
llvm-svn: 309340
The problem was that if base_name() was called from a context without
an actual base name, it could gulp up the entire string, which can
result in recursive duplications. The fix is to be more strict as to
what qualifies as a base name.
Differential revision: https://reviews.llvm.org/D33637
llvm-svn: 304113
Summary:
Previously if we parsed a constructor then we set parsed_ctor_dtor_cv
to true and never reseted it. This causes issue when a template argument
references a constructor (e.g. type of lambda defined inside a
constructor) as we will have the parsed_ctor_dtor_cv flag set what will
cause issues when parsing later arguments.
Reviewers: EricWF, compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33385
llvm-svn: 303737
The problem is that multiple types could have been parsed from parse_type(),
which the lamdba parameter parsing didn't handle.
Differential revision: https://reviews.llvm.org/D33368
llvm-svn: 303718
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302978 and r302981, which were reverted in r303016
because a libcxx test was failing on an AArch64 bot. I also modified the
libcxxabi test case to check the alignment of the pointer returned by
__cxa_allocate_exception rather than compiling the test with -O1 and
checking whether it segfaults.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 303175
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302763 with fixes to RUN lines in the test case.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302978
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302763
This test fails on ARM bare-metal targets because it assumes the Itanium ABI,
whereas EHABI requires the exception address to be 8-byte aligned.
I was a bit puzzled at first because this should've failed on the public
arm-linux builder too. I think the reason it passes there is because we don't
include libunwind headers in the include path when running the libcxxabi tests,
so the system unwind.h gets picked up.
Reviewers: rengolin, EricWF
Differential revision: https://reviews.llvm.org/D31178
llvm-svn: 299435
Summary: It's now completely empty, so we can remove it entirely.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31502
llvm-svn: 299129
Summary:
In 32 bit builds on a 64 bit system `std::malloc` does not return correctly aligned memory. This leads to undefined behavior.
This patch switches to using `posix_memalign` to allocate correctly aligned memory instead.
Reviewers: mclow.lists, danalbert, jroelofs, compnerd
Reviewed By: compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25417
llvm-svn: 296952
These tests embed calls to exceptions-related symbols from the abi library,
which are absent in the no-exceptions variant. The tests need to be marked
as unsupported for the no-exceptions configuration.
llvm-svn: 296344
When checking if the type is a r-value ref, we would not do a complete
check. This would result in us treating a trailing parameter reference
`&)` as a r-value ref, and improperly inject the cv qualifier on the
type. We now correctly demangle the type `KFvRmE` as a constant
function rather than a constant reference.
Fixes PR31741!
llvm-svn: 292973
Fix an off-by-one case which would destroy the final parameter in a
CV-qualified function type with a reference. We still get the CV
qualification incorrect, but at least we do not clobber the type name
any longer.
Partially fixes PR31741.
llvm-svn: 292963
Pending LIT changes are about to remove the REQUIRES-ANY keyword
in place of supporting boolean && and || within "REQUIRES". This
patch prepares libc++ for that change so that when applied
the bots don't lose their mind.
llvm-svn: 292906
This test contained an implicit conversion from nullptr to bool.
Clang warns about this but the test had supressed that warning.
However GCC diagnoses the same code as an error and requires
-fpermissive to accept it.
This patch fixes both the warning and the error by explicitly
converting the pointer to bool.
llvm-svn: 292638
The Itanium ABI [1] specifies that __cxa_demangle accept either:
1) symbol names, which start with "_Z"
2) type manglings, which do not start with "_Z"
r286788 erroneously assumes that it should only handle symbols, so this patch
reverts it and adds a counterexample to the testcase.
1: https://mentorembedded.github.io/cxx-abi/abi.html#demangler
Reviewers: zygoloid, EricWF
llvm-svn: 292418
+ Now that libcxxabi shares the same threading API as libcxx, a whole
chunk of code in src/config.h is made redundant (I missed this earlier).
+ r291275 split off the externalized-thread-api libcxx configuration from the
external-thread-library libcxx configuration. libcxxabi should follow the
same approach.
llvm-svn: 291440
r281179 Introduced an externally threaded variant of the libc++ library. This
patch adds support for a similar library variant for libc++abi.
Differential revision: https://reviews.llvm.org/D27575
Reviewers: EricWF
llvm-svn: 290888
The macOS thread-local variable finalizer routines do not handle the
case where a termination function registers another termination function
correctly, causing this test to fail. I've filed a radar for this;
mark the test XFAIL in the meantime. See [1] for more details.
[1] http://lists.llvm.org/pipermail/cfe-dev/2016-November/051376.html
Differential Revision: https://reviews.llvm.org/D27434
llvm-svn: 289513
The block invocation function uses an extension where the prefix is ___Z
as opposed to _Z. This should make the tests pass again.
Disable a negative test which was testing a crasher. The symbol being
demangled is not a valid mangled symbol and will return a nullptr.
Adjust the type info decoding test to be a valid symbol name.
llvm-svn: 286793
GCC 4.7 or newer emits 0x90 (indirect | pcrel) as the ttype encoding.
This would hit an assertion in cxa_personality.cpp. This commit fixes
the problem by relaxing the assertion.
llvm-svn: 286760
This patch refactors all pthread uses of libc++abi into a separate API. This
is the first step towards supporting an externlly-threaded libc++abi library.
I've followed the conventions already used in the libc++ library for the same
purpose.
Patch from: Saleem Abdulrasool and Asiri Rathnayake
Reviewed by: compnerd, EricWF
Differential revisions:
https://reviews.llvm.org/D18482 (original)
https://reviews.llvm.org/D24864 (final)
llvm-svn: 284128
Throwing an exception for the first time may lead to call calloc to
allocate memory for __cxa_eh_globals. If the memory pool is exhausted
at that moment, it results in abnormal termination of the program.
This patch addresses the issue by using fallback_malloc in that case.
In this revision, some restrictions were added into the test to not
run it in unsuitable environments.
Differential Revision: https://reviews.llvm.org/D17815
llvm-svn: 283531
Throwing an exception for the first time may lead to call calloc to
allocate memory for __cxa_eh_globals. If the memory pool is exhausted
at that moment, it results in abnormal termination of the program.
This patch addresses the issue by using fallback_malloc in that case.
Differential Revision: https://reviews.llvm.org/D17815
llvm-svn: 282692
This patch (and commit summary) mirror r279675 by Chris B which was applied
to libc++ but not libc++abi.
Summary:
The point of this patch is to have a consistent convention for naming build,
check and install targets so that the targets can be constructed from the
project name.
This change renames a bunch of CMake components and targets from libcxxabi to
cxxabi. For each renamed target I've added a convenience target that matches
the old target name and depends on the new target. This will preserve function
of the old targets so that the change doesn't break the world. We can evaluate
if it is worth removing the extra targets later.
llvm-svn: 279938
This patch applies changes similar to those in r279515 to libc++abi.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXXABI_BUILT_STANDALONE -> LIBCXXABI_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
llvm-svn: 279936
When we're running tests under ASAN or MSAN, they're compiled with -O1, which
enables tail call elimination. This causes backtrace_test to fail: the compiler
performs tail call elimination for call3_nothrow, but it can't for call3_throw,
leading to a mismatched frame count. Disable tail call elimination (and
inlining, just to be explicit) to avoid this.
Patch by Shoaib Meenai!
llvm-svn: 279935
When libcxxabi is being built standalone, unwind dependency is not
available, so do not use it even when LLVM unwinder is being
requested.
Differential Revision: https://reviews.llvm.org/D23228
llvm-svn: 278058
pointer-to-member type, produce a null value of the right type.
This fixes a bug where throwing an exception of type nullptr_t and catching it
as a pointer-to-member would not guarantee to produce a null value in the catch
handler. The fix is pretty simple: we statically allocate a constant null
pointer-to-data-member representation and a constant null
pointer-to-member-function representation, and produce the address of the
relevant value as the adjusted pointer for the exception.
llvm-svn: 276016
Summary:
This patch fixes -Wreorder warnings on test classes with virtual bases. Since the compiler is performing the reordering anyway this change *should* have NFC.
However the test notes that it is checking that "virtual base classes work properly". Since initialization order is clearly part of correctness I want to confirm that this wasn't an intentional mistake.
Reviewers: mclow.lists, howard.hinnant
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21396
llvm-svn: 272821
Summary:
This patch changes the libc++abi CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including `config-ix.cmake`.
Since these flags can affect things like `check_library_exists([...])` they needed to be added before the tests are performed.
Additionally this patch adds `LIBCXXABI_BUILD_32_BITS` which defaults to `LLVM_BUILD_32_BITS`.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=27950https://llvm.org/bugs/show_bug.cgi?id=27959
Reviewers: danalbert, jroelofs, bcraig, compnerd, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20886
llvm-svn: 271470
Currently there is only support for a -fno-exceptions libc++ build. This is
problematic for functions such as std::terminate() which are defined in
libc++abi and using any of those functions throws away most of the benefits
of using -fno-exceptions (code-size). This patch introduces a -fno-exceptions
libc++abi build to address this issue.
This new variant of libc++abi cannot be linked against any with-exceptions
code as some symbols necessary for handling exceptions are missing in this
library.
Differential revision: http://reviews.llvm.org/D20677
Reviewers: EricWF, mclow.lists, bcraig
llvm-svn: 271267
This change leverages framework changes made in libcxx. See those changes for
more details. (http://reviews.llvm.org/D16544)
Some Mac specific logic for testing against libc++abi had to be moved from
libcxxabi's config.py, as it was overriding choices made in libcxx's config.py.
That logic is now in libcxx's target_info.py.
http://reviews.llvm.org/D16545
llvm-svn: 266729
The feature check is already in place when building the library but wasn't
honored for the tests.
Differential Revision: http://reviews.llvm.org/D18205
llvm-svn: 263699
This test has a lot of classes with large amounts of manually inserted padding in them, presumably to prevent various optimizations. The test then creates lots of these objects on the stack. On embedded targets, this was usually enough to overflow the stack.
I moved the objects to global / namespace scope. Since the tests are each in their own namespace, there should be no cross-test conflicts.
llvm-svn: 262717
libcxxabi uses the C99 library's %a format specifier to turn a floating
point value into a hexadecimal string representation. The %a format
specifier is rather loosely defined in the C spec though, and some C
libraries emit a different (but valid) string for a given floating
point value. In particular, the C spec only requires that there is a
single, non-zero hexadecimal digit on the left of the decimal point.
Given that constraint, there are typically four different valid
representations of a floating point number. I have updated the test to
accept any of the valid representations for demangled floating
point literals.
llvm-svn: 258311
This patch re-commits r256322 and r256323. They were reverted due to a OS X
test failure. The test failure has been fixed by libc++ commit r258217.
This patch also adds some additional tests.
llvm-svn: 258249
Currently, the tests assume the system compiler is the one we want
to test, but if we build libcxxabi together with LLVM+Clang, it'll
get the wrong compiler.
This patch allows us to test if we have clang++ in our /bin directory,
and if so, use it.
llvm-svn: 243752
Summary:
backtrace_test.pass.cpp depends on unwind tables. These are generated by
-funwind-tables which is the default for x86 but not for other targets.
Thanks to Nitesh Jain for helping to narrow this down.
Fixes PR24148
Reviewers: jroelofs
Subscribers: cfe-commits, jroelofs, llvm-commits, hans
Differential Revision: http://reviews.llvm.org/D11529
llvm-svn: 243296
Function pointers and member function pointers cannot be converted to void*.
libc++abi incorrectly allows this conversion for function pointers.
Review URL: http://reviews.llvm.org/D8811
llvm-svn: 236299
Summary:
I accidentally implemented the 4.11 [conv.mem] conversions for libc++abi in a recent patch. @majnemer pointed out that 5.13 [except.handle] only allows the pointer conversions in 4.10 and not those is 4.11. This patch no longer allows the following example code:
```c++
struct A {};
struct B : public A {};
int main() {
try {
throw (int A::*)0;
} catch (int B::*) {
// exception caught here.
}
}
```
Reviewers: mclow.lists, jroelofs, majnemer
Reviewed By: majnemer
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D8845
llvm-svn: 234254
Summary:
Currently there are bugs in out detection of multi-level pointer conversions and pointer to member conversions. This patch fixes the following issues.
* Allow multi-level pointers with different nested qualifiers.
* Allow multi-level mixed pointers to objects and pointers to members with different nested qualifiers.
* Allow conversions from `int Base::*` to `int Derived::*` but only for non-nested pointers.
There is still some work that needs to be done to clean this patch up but I want to get some input on it.
Open questions:
* Does `__pointer_to_member_type_info::can_catch(...)` need to adjust the pointer if a base to derived conversion is performed?
Reviewers: danalbert, compnerd, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8758
llvm-svn: 233984
Summary:
This patch builds both static and shared versions of libc++abi by default. It adds/repurposes the following cmake options:
* `LIBCXXABI_ENABLE_SHARED`: Enable/disable building the shared library. (Previously using `OFF` would build the static library instead)
* `LIBCXXABI_ENABLE_STATIC`: Enable/disable building the static library.
This patch also re-purposes the CMake target `cxxabi` to be a meta-target for `cxxabi_shared` and `cxxabi_static`. This could potentially break other builds that depend on `cxxabi` being a library target. We will need to apply a patch to libc++'s CMake before committing this change.
Running the tests is still only supported when the shared version is built. Support for running the tests against the static library will come in another patch.
Reviewers: jroelofs, mclow.lists, danalbert, compnerd
Reviewed By: danalbert, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8013
llvm-svn: 231075
Summary:
The main section of this patch teaches CMake a new option `LIBCXXABI_LIBCXX_PATH` that specifies the path to the libcxx source root. This information is passed to lit so that it can better find libc++'s python module. `LIBCXXABI_LIBCXX_PATH` is also used to help find the libc++ headers.
The rest of this patch is misc cleanup, mostly to make pep8 and pylint happy.
I've also copied libc++'s .gitignore into libc++abi.
Reviewers: jroelofs, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7130
llvm-svn: 226855
libdir suffixes like 'lib64' or 'lib32'.
This support is currently very rhudimentary. We define a variable
LIBCXXABI_LIBDIR_SUFFIX. In a standalone build of libc++abi this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++abi within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.
Unfortunately, libc++abi's lit setup made this somewhat problematic to
change. It was setting variables up in a way that caused the resulting
build to not work with lit at all. To fix that, I've moved some
variables around in the CMake build to more closely match where and how
they are defined in the libc++ CMake build. This includes specifically
defining a library root variable in the CMake build where the libdir
suffix can be applied, and then using that rather than re-computing it
from the object directory in the lit config.
This is essentially new functionality for libc++abi so I don't expect it
to have any impact for folks until they start setting these variables.
However, I know libc++abi is built in a diverse set of environments so
just let me know if this causes you any problems.
llvm-svn: 224927
Eric Fiselier