This test has been failing on some SDKs for a long time because we lack
a proper way of identifying the SDK version in Lit. Until that is possible,
mark the test as unsupported on Apple to restore the CI.
This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.
This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
Instead of detecting it automatically (in libc++) and relying on
_LIBCXXABI_NO_EXCEPTIONS being set explicitly (in libc++abi), always
detect whether exceptions are enabled automatically.
This commit also removes support for specifying -D_LIBCPP_NO_EXCEPTIONS
and -D_LIBCXXABI_NO_EXCEPTIONS explicitly -- those should just be inferred
from using -fno-exceptions (or an equivalent flag).
Allowing both -D_FOO_NO_EXCEPTIONS to be provided explicitly and trying
to detect it automatically is just confusing, especially since we did
specify it explicitly when building libc++abi. We should have only one
way to detect whether exceptions are enabled, but it should be robust.
I ran into an error while trying to build libc++abi for a platform that
doesn't have <sys/types.h>. I couldn't find what <sys/types.h> was used
for in the header, so I think it's fine to remove it.
Differential Revision: https://reviews.llvm.org/D82810
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
This is necessary for standalone builds where the libc++ in use has a
custom configuration set up inside __config_site -- one needs to build
libc++abi against the installed headers of libc++ (which are properly
configured) instead of the ones inside libcxx/include.
See https://reviews.llvm.org/rGe619e9d#927848 for details.
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.
This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.
Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
Since we have the monorepo, libc++abi's build requires a sibling checkout
of the libc++ sources. Hence, the logic for finding libc++ can be greatly
simplified.
Instead of passing file dependencies individually, assume that the
whole content of the unique test directory is a dependency. This
simplifies the test harness significantly, by making %T the directory
that contains everything required to run a test. This also removes the
need for the %{file_dependencies} substitution, which is removed by this
patch.
Furthermore, this patch also changes the harness to execute tests locally
inside %T, so as to avoid creating a separate directory for no purpose.
This clarifies the difference between test for exception support in
libc++abi tests and support for exceptions built into libc++abi.
This also removes the rather confusing similarity between the
_LIBCXXABI_NO_EXCEPTIONS and LIBCXXABI_HAS_NO_EXCEPTIONS macros.
Finally, TEST_HAS_NO_EXCEPTIONS is also detected automatically based
on -fno-exceptions, so it doesn't have to be specified explicitly
through Lit's compile_flags.
0e04342ae0 simplified exceptions-related configurations for libc++abi
and libunwind by reusing the logic in libc++. However, it missed the fact
that libc++abi and libunwind were overriding libc++'s handling of exceptions.
This commit removes special handling in libc++abi and libunwind to use
the logic in libc++, which is the right one.
First, libc++abi doesn't need to add the no-exceptions Lit feature itself,
since that is already done in the config.py for libc++, which it reuses.
Specifically, config.enable_exceptions is set based on @LIBCXXABI_ENABLE_EXCEPTIONS@
in libc++abi's lit.cfg.in, and libc++'s config.py handles that correctly.
Secondly, libunwind's LIBUNWIND_ENABLE_EXCEPTIONS is never set (it's
probably a remnant of copy-pasting code between the runtime libraries),
so the library is always built with exceptions disabled (which makes
sense since it implements the runtime support for exceptions).
Conversely, the test suite is always run with exceptions enabled
(not sure why), but that is preserved by the default behavior of
libc++'s config.py.
Since <unwind.h> is in the SDK, not in /usr/include, the XFAILs must
be predicated on the compiler version (ideally even on the SDK version)
instead of the target system version.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
When building the system libc++abi for Apple, we use CrashReporterClient
to provide better crash logs when calling abort(). This is exemplified by
the fact that we test for the presence of <CrashReporterClient.h> in
abort_message.cpp.
However, we must link against CrashReporterClient.a in order to get that
functionality, otherwise we get a linking error.
Slightly older Clangs seem to think they are more clever than they really
are, and they think the code can never be executed. The code can actually
be executed in case the exception runtime is mis-implemented, which is
exactly what this test is testing. This commit just disables the spurious
warning.
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.
Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines
Differential Revision: https://reviews.llvm.org/D78787
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.
Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
This upstreams a fix that Howard made a long time ago, where so many
errors would be logged that applications were becoming sluggish. With
this patch, the first three errors will be printed, and after that the
printing frequency decreases exponentially.
_LIBCXX_DYNAMIC_FALLBACK is only enabled on Apple platforms, so this
should be NFC for other platforms.
rdar://14996273
Differential Revision: https://reviews.llvm.org/D78330
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
Summary:
This patch is to fix the parsing of long double literals encoded with the e prefix on PowerPC and S390. For both PowerPC and S390, type code e is used for 64-bit long double literals and g is used for 128-bit long double literals. libcxxabi test case test_demangle.pass.cpp fails without the fix.
Authored by: xingxue-ibm
Reviewers: hubert.reinterpretcast, jasonliu, erik.pilkington, uweigand, mclow.li
sts, libc++abi
Reviewed by: hubert.reinterpretcast, erik.pilkington
Differential Revision: https://reviews.llvm.org/D74163
The new format should be equivalent to the old format, and it is now the
default format when running the libc++ tests. This commit changes the
libc++abi tests to use the new format by default too. If unexpected failures
are discovered, it should be fine to revert this commit until they are
addressed.
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
The LitConfig is shared across the whole test suite. However, since
enabling recursive expansion can be a breaking change for some test
suites, it's important to confine the setting to test suites that
enable it explicitly.
Note that other issues were raised with the way recursiveExpansionLimit
operates. However, this commit simply moves the setting to the right
place -- the mechanism by which it works can be improved independently.
Differential Revision: https://reviews.llvm.org/D77415
This new test format is simpler and more flexible. It creates Lit ShTests
on the fly that reuse existing substitutions (like %{cxx}) instead of
having complex logic in Python to run the tests. This has the benefit
that virtually no coding is required to customize how the test suite is
run -- one can achieve pretty much anything by defining the appropriate
substitutions in a simple lit.cfg file.
For example, in order to run the tests on an embedded device after
building with a specific SDK, one can set the %{cxx} and %{compile_flags}
substitutions to use that SDK, and the %{exec} substitution to the ssh.py
script currently used for .sh.cpp tests with a remote executor. Dealing with
the SSHExecutor becomes unnecessary, since all tests are treated like ShTests.
As a side effect of this design, configuration files for the test
suite can be as simple as:
config.substitutions.append(('%{cxx}', '<path-to-compiler>'))
config.substitutions.append(('%{compile_flags}', '<flags>'))
config.substitutions.append(('%{link_flags}', '<flags>'))
config.substitutions.append(('%{exec}', '<script-to-execute>'))
This should allow storing lit.cfg files for various configurations
directly in the repository instead of relying on complicated logic
in config.py to set up the right flags. I've found numerous problems
in that logic in the past years, and it seems like having simple and
explicit configuration files for the configurations we support is
going to solve most of these problems. Specifically, I am hoping to
store configuration files for testing other Standard Libraries in
the repository.
Improving the interaction with the test suite configuration is still a
work in progress, so for now this test format reuses the substitutions and
available features that are set up by the current config.py.
This new test format should support pretty much everything that the current
test format supports, however it will not be enabled by default at first to
make sure we're satisfied with it. For a short period of time, the new format
will require `--param=use_new_format=True` to be enabled, however it is a very
short term goal to replace the current testing format entirely and to simplify
the configuration accordingly.
Differential Revision: https://reviews.llvm.org/D77338
To avoid wasting the valuable time of contributors, add a link to a
blocked review to document additional issues with the removal of some
GCC 4.9 workaround.
We will soon start removing technical debt and sharing code between the
two directories, so this first step is meant to discover potential places
where the libraries are built outside of a monorepo layout. I imagine
this could happen as a remnant of the pre-monorepo setup.
This was discussed on the libcxx-dev mailing list and we got overall
consensus on the direction. All consumers of libc++ and libc++abi
should already be doing so through the monorepo, however it is
possible that we catch some stragglers with this patch, in which
case it may need to be reverted temporarily.
Differential Revision: https://reviews.llvm.org/D76102
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
This is a re-application of f383fb40b1, wich was reverted in 04d48111b
because the build bots had not been updated yet. The build bot configurations
have now been updated not to use the deprecated targets, and I verified
that they were using the non-deprecated targets, so we should be good
unless I missed a bot.
Differential Revision: https://reviews.llvm.org/D76104
lit is not very clever when it performs substitution on RUN lines. It
simply looks for a match anywhere in the line (without tokenization)
and replaces it by the expansion. This means that a RUN line containing
e.g. `-verify-ignore-unexpected=note` wouod be expanded to
`-verify-ignore-unexpected=<substitution for not>e`, which is
surprising and nonsensical.
It also means that something like `%compile_module` could be expanded
to `<substitution-for-%compile>_module` or to the correct substitution,
depending on the order in which substitutions are evaluated by lit.
To avoid such problems, it is a good habit to delimit custom substitutions
with some token. This commit does that for all substitutions used in the
libc++ and libc++abi test suites.
This reverts commit f383fb40b. It looks like several of our build bots
are still using the legacy target names, so we'll change those before
we commit this change again.
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
There's no doubt this commit will break some CI systems, however the
fix is trivial.
Differential Revision: https://reviews.llvm.org/D76104
Since the atomic_support.h header of libc++abi is considered technical
debt (since we should use libc++'s), it's better not to add new
definitions to it, which makes it diverge from the original libc++
header even more.
Differential Revision: https://reviews.llvm.org/D75950
It seems to me that abort_message.h is always included in a C++ file, so
it's fine to assume that it's C++ code.
Differential Revision: https://reviews.llvm.org/D76027
Summary:
The return type of __cxa_finalize is documented as void in the Itanium
C++ ABI, and it is void in various C libraries.
Reviewers: EricWF, ldionne, compnerd, mclow.lists, MaskRay
Reviewed By: MaskRay
Subscribers: MaskRay, dexonsmith, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75795
Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined -
just check _WIN64 in addition to __LP64__.
This fixes compilation after static asserts about the struct layout
were added in f2a436058f.
Differential Revision: https://reviews.llvm.org/D73838
Summary:
Preserve the old ABI for __cxa_exception and __cxa_dependent_exception
on 64 bit platforms or ARM_EHABI platforms.
After r276215, libunwind in llvm-project labels _Unwind_Exception to be
double word aligned. That change implictly adds a padding before
unwindHeader field in __cxa_exception and __cxa_dependent_exception.
Preserve the same negative offsets in those struct by moving the padding
to the beginning of the field.
The assumption here is that if the ABI is not aware of the padding before
unwindHeader and put the referenceCount/primaryException in there, no padding
should exist before unwindHeader.
Reviewers: EricWF, mclow.lists, ldionne, jroelofs, dexonsmith, rjmccall, compnerd, phosek, ahatanak
Reviewed By: rjmccall
Subscribers: hans, smeenai, kristof.beyls, christof, jkorous, ributzka, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72543
libc++ on Android needs to be linked against libandroid_support on API
levels less than 21 to provide needed functions that aren't in the libc
on those platforms (e.g. posix_memalign for libcxxabi). libc++ from the
NDK is a linker script that pulls in libandroid_support, but for
building libc++ itself, we need to explicitly add libandroid_support as
a dependency. Moreover, libc++ headers reference the functions provided
by libandroid_support, so it needs to be added as a public dependency.
Differential Revision: https://reviews.llvm.org/D73516
These names have been changed from CamelCase to camelCase, but there were
many places (comments mostly) that still used the old names.
This change is NFC.
builds.
Fix a libc++abi test that was incorrectly checking for threading
primitives even when threading was disabled.
Additionally, temporarily XFAIL some module tests that fail because
the <atomic> header is unsupported but still built as a part of the
std module.
To properly address this libc++ would either need to produce a different
module.modulemap for single-threaded configurations, or it would need
to make the <atomic> header not hard-error and instead be empty
for single-threaded configurations
Summary:
Right now the only way to force libc++abi tests to link with the static version of libc++abi is to set `LIBCXXABI_ENABLE_SHARED` to `OFF`. However, this doesn't work when libc++abi is built as standalone project because of [this](54c5224203/libcxxabi/CMakeLists.txt (L503-L519)).
This change allows specifying the version of the library for tests to link with.
This is useful for remote testing, for example, with `SSHExecutor`, where we _have_ to link with libc++abi statically.
Two new CMake options are introduced here: `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI` and `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX`. They can be set to `OFF` to tell the test utility to link tests with the static libraries.
It shouldn't break anything, because the default values of these options are set such that the test utility will behave the same way.
Reviewers: EricWF, mclow.lists, phosek, mehdi_amini, ldionne, jroelofs, bcraig
Subscribers: mgorny, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71894
These are a part of the libc so linking these explicitly isn't necessary
and embedding these as deplibs causes link time error.
This issues was introduced in a9b5fff which changed how we emit deplibs.
Differential Revision: https://reviews.llvm.org/D71135
This is a followup to 35bc5276ca. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
detects them, rather than based on explicit platform blacklist.
Differential Revision: https://reviews.llvm.org/D70888
We build with `-nostdinc++` and add our own header path via
`LIBCXXABI_LIBCXX_INCLUDES`. However cmake tried to be clever and if
`LIBCXXABI_LIBCXX_INCLUDES` happens to match the compilers system path
it will remove the `-I` flag meaning we can't access any C++ headers.
Ideally cmake would be able see that we are using `-nostdinc++` and
disable this behaviour.
Differential Revision: https://reviews.llvm.org/D69973
This class was a bit overengineered, and was triggering some PVS warnings.
Instead, put strings into a NameType and let clients unconditionally treat it
as a Node.
Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
llvm-svn: 375307
That option controls the 'VERSION' attribute of the libc++abi shared
library, which in turn controls the name of the actual dylib being
produced.
llvm-svn: 373949
These flags are already set when we create the cxxabi_shared target
using the SOVERSION and VERSION target properties, and the install_name
was already being overriden to '@rpath/libc++abi.1.dylib' by CMake
because no 'CMAKE_INSTALL_NAME_DIR' option was specified. So this is
effectively a removal of dead code with no intended functionality change.
The only think we're losing here is that we used to link against
libSystem.B.dylib instead of libSystem.dylib when building libc++abi
for macOS 10.6 -- however, I strongly suspect nobody's building
libc++abi from source for that target anymore.
llvm-svn: 373934
On Apple platforms, libSystem is an umbrella for all other system
libraries, and libpthread (and friends) are actually just symlinks
to libSystem.
llvm-svn: 373770
Summary:
Those functions started being mistakenly exported from the libc++abi
shared library after commit r344152 in 2018. Removing these symbols is
technically an ABI break. However, they are not part of the C++ ABI,
they haven't ever been re-exported from libc++, and they are not
declared in any public header, so it's very unlikely that calls to
these functions exist out there. Also, the functions have reserved
names, so any impacted user would have to have tried really hard
being broken by this removal.
Note that avoiding this kind of problem is exactly why we're now
controlling exported symbols explicitly with a textual list.
Also note that applying the hidden visibility attribute is necessary
because the list of exported symbols is only used on Apple platforms
for the time being.
Reviewers: phosek, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68357
llvm-svn: 373602
This reduces the (circular) dependency of libc++abi on a C++ standard
library. Outside of the demangler which uses fancier C++ features, the
only C++ headers now required by libc++abi are pretty much <new> and
<exception>, and that's because libc++abi defines some types that are
declared in those headers.
llvm-svn: 373381
Both arm32 armv7/armv8 bots which do not use compiler-rt are failing
to a linking issue:
[100%] Built target cxxabi_static
CMakeFiles/cxxabi_shared.dir/cxa_demangle.cpp.o: In function `(anonymous namespace)::itanium_demangle::OutputStream::writeUnsigned(unsigned long long, bool)':
/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/llvm/projects/libcxxabi/src/demangle/Utility.h:55: undefined reference to `__aeabi_uldivmod'
/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/llvm/projects/libcxxabi/src/demangle/Utility.h:56: undefined reference to `__aeabi_uldivmod'
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
It seems after r371273 OutputStream is used more extensively and
is pulling OutputStream::writeUnsigned (which thus requires unsigned
integer module).
The straightfoward fix is to explicit link against libgcc if
compiler-rt is not used.
llvm-svn: 372921
version after r371273.
Also fix a minor issue in r371273 that only surfaced after template
instantiation from LLVM's use of the demangler.
llvm-svn: 371274
This implements demangling support for the mangling extensions specified
in https://github.com/itanium-cxx-abi/cxx-abi/pull/85, much of which is
implemented in Clang r359967 and r371004.
Specifically, this provides demangling for:
* <template-param-decl> in <lambda-sig>
* <template-param> with non-zero level
* lambda-expression literals (not emitted by Clang yet)
* nullptr literals
* string literals
(The final two seem unrelated, but handling them was necessary in order
to disambiguate between lambda expressions and the other forms of
literal for which we have a type but no value.)
When demangling a <lambda-sig>, we form template parameters with no
corresponding argument, so we cannot substitute in the argument in the
demangling. Instead we invent synthetic names for the template
parameters (eg, '[]<typename $T>($T *x)').
llvm-svn: 371273
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
Louis Dionne