Summary: This patch adds a check for if -std=c++11 is a supported flag, and adds it to CMAKE_CXX_FLAGS if it is supported.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24007
llvm-svn: 280021
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 using libunwind and not building as standalone project, we
can directly depend on the unwind library target.
Differential Revision: https://reviews.llvm.org/D23289
llvm-svn: 278169
When using libunwind and not building as standalone project, we
need to add LLVM library directory to the list of linker directories
to ensure it can find libunwind dependency.
Differential Revision: https://reviews.llvm.org/D23287
llvm-svn: 278076
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
Add an option to opt into compiler-rt instead of libgcc. This option defaults
to OFF to avoid a behaviour change. It is not possible to mix and match
different runtime libraries. Disabling this requires that libc++ is built
accordingly. This knob is particularly useful for targets that are GCC by
default (i.e. Linux).
llvm-svn: 275505
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
This patch breaks the ABI on linux when libc++abi.a is statically linked into
libc++.so. Certain libc++ symbols get exported from libc++abi.a as hidden
and therefore they also get hidden in libc++.so.
The symbols is question are:
* _ZNKSt3__121__basic_string_commonILb1EE20__throw_out_of_rangeEv
* _ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv
* _ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv
I imagine we just need to fix the visibility for these symbols in the libc++
headers but I'm reverting the patch until it's sorted.
llvm-svn: 271500
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
Enable building libc++abi with hidden visibility by default. The ABI mandated
interfaces (and a few extra) are already set up to be externally visible. This
allows us to ensure that any implementation details are not leaked.
llvm-svn: 270816
When building libcxxabi in tree (i.e. in llvm/projects/libcxxabi,
along with llvm/projects/libcxx), libcxx's config_site.in doesn't
get created in a timely manner. This means that any configuration
that is normally set in libcxx's config_site.in needs to be
duplicated in libcxxabi to successfully build libcxxabi. This patch
does exactly that for the _LIBCPP_HAS_THREAD_API_PTHREAD
preprocessor define.
http://reviews.llvm.org/D20574
llvm-svn: 270732
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
Prior to this patch, setting LIBCXXABI_LIBDIR_SUFFIX would confuse the
check-libcxxabi target. libc++abi.* would get output to lib instead of
lib${LIBCXXABI_LIBDIR_SUFFIX}, but the tests would look in the suffixed
directory.
Now, we match what libcxx does, and set the CMAKE_*_OUTPUT_DIRECTORY to the
LIBRARY_DIR.
http://reviews.llvm.org/D17410
llvm-svn: 266611
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
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: 258222
This commit adds SHF_ALLOC and SHF_EXECINSTR section flags to
`.text.__cxa_end_cleanup` section. This fixes a link error when we are
using integrated-as and `ld.gold` (with `-Wl,--gc-sections` and
`-Wl,--fatal-warnings`.)
Detailed Explanation:
1. There might be some problem with LLVM integrated-as. It is not
emitting any section flags for text sections. (This will be fixed in
an independent commit.)
2. `ld.gold` will skip the external symbols in the section without
SHF_ALLOC. This is the reason why `.text.__cxa_end_cleanup_impl`
section is discarded even though it is referenced by
`__cxa_end_cleanup()`.
This commit workaround the problem by specifying the section flags
explicitly.
Fix http://llvm.org/PR21292
llvm-svn: 256241
Summary:
libgcc_eh.a cannot be used when building libc++abi as a shared library (the default configuration). See this post for some more discussion: https://gcc.gnu.org/ml/gcc/2012-03/msg00104.html
This patch reverts back to using libgcc_s when linking libc++abi.so.
Reviewers: danalbert, chandlerc, mclow.lists, ismail, compnerd
Subscribers: vkalintiris, cfe-commits
Differential Revision: http://reviews.llvm.org/D15440
llvm-svn: 255559
Chris Bieneman