The Android sanitizer buildbot is failing with this change and it
looks like an additional change to cmake is necessary to fix the
build. Reverting this change for now.
llvm-svn: 329828
CMAKE_CXX_FLAGS was added twice to the command line. This causes the command
line options to be doubled which works until it doesn't as not all options
can be specified twice.
For example,
clang-cl foo.c /GS- /GS- -mllvm -small-loop-cost=1 -mllvm -small-loop-cost=1
clang (LLVM option parsing): for the -small-loop-cost option: may only occur zero or one times!
llvm-svn: 329817
This changes the add_custom_libcxx macro to resemble the
llvm_ExternalProject_Add. The primary motivation is to avoid
unnecessary libFuzzer rebuilds that are being done on every
Ninja/Make invocation. The libc++ should be only rebuilt whenever
the libc++ source itself changes.
Differential Revision: https://reviews.llvm.org/D43213
llvm-svn: 326921
`set_target_compile_flags()` ultimately sets COMPILE_FLAGS which is
added to CMAKE_CXX_FLAGS in the compile rule, so passing
CMAKE_CXX_FLAGS causes them to be duplicated.
Differential Revision: https://reviews.llvm.org/D42398
llvm-svn: 323626
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42462
llvm-svn: 323606
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323054
add_custom_libcxx uses the just built compiler and installs the
built libc++, e.g. for testing, neither of which is desirable in
case of Fuzzer where the libc++ should be built using the host
compiler and it's only linked into the libFuzzer and should never
be installed. This change introduces additional arguments to
add_custom_libcxx to allow parametrizing its behavior.
Differential Revision: https://reviews.llvm.org/D42330
llvm-svn: 323032
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322451
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322256
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322234
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322153
This also slightly refactors the code that's checking the directory
presence which allows eliminating one unnecessary variable.
Differential Revision: https://reviews.llvm.org/D40637
llvm-svn: 320446
These targets strip during installation, and are required to support
install-distribution-stripped in LLVM (to support a stripped
distribution). LLVM has an add_llvm_install_targets function for this
purpose, but we can't rely on LLVM being present.
Differential Revision: https://reviews.llvm.org/D40687
llvm-svn: 319569
Now that we have disabled the run-forever tests, and cleaned up the
intel 80-bit float based tests, we should be able to enable testing
compiler-rt for powerpc64.
llvm-svn: 319474
This renames ASM_TSAN_SYMBOL and ASM_TSAN_SYMBOL_INTERCEPTOR to just ASM_SYMBOL and ASM_SYMBOL_INTERCEPTOR, because they can be useful in more places than just TSan. Also introduce a CMake function to add ASM sources to a target.
Differential Revision: https://reviews.llvm.org/D40143
llvm-svn: 319339
Multi-config CMake generators need lit to be able to resolve paths of
artifacts from previous build steps at lit time, rather than expect them
to be fully resolved at CMake time as they may contain the build mode.
Differential Revision: https://reviews.llvm.org/D38471
llvm-svn: 318037
Fix typo in variable assignment inside sanitizer_test_compile() that
resulted in TEST_DEPS parameter not being included in the clang_compile()
call. Spotted by George Karpenkov in D38444.
Differential Revision: https://reviews.llvm.org/D38838
llvm-svn: 315604
Summary:
Some architecture-specific function overrides (for example, i386/ashrdi3.S)
duplicate generic functions (in that case, ashrdi3.c). Prevent duplicate definitions
by filtering out the generic files before compiling.
Reviewers: compnerd, beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37166
llvm-svn: 312140
Summary:
Recent changes canonicalized clang_rt library names to refer to
"i386" on all x86 targets. Android historically uses i686.
This change adds a special case to keep i686 in all clang_rt
libraries when targeting Android.
Reviewers: hans, mgorny, beanz
Subscribers: srhines, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37278
llvm-svn: 312048
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311924
- Not having a dependency does not work in standalone build, as Clang does not exist.
- if (TARGET clang) check is useless, as it is order-dependent,
and Clang may not be registered yet.
Differential Revision: https://reviews.llvm.org/D37228
llvm-svn: 311911
Remove the explicit i686 target that is completely duplicate to
the i386 target, with the latter being used more commonly.
1. The runtime built for i686 will be identical to the one built for
i386.
2. Supporting both -i386 and -i686 suffixes causes unnecessary confusion
on the clang end which has to expect either of them.
3. The checks are based on wrong assumption that __i686__ is defined for
all newer x86 CPUs. In fact, it is only declared when -march=i686 is
explicitly used. It is not available when a more specific (or newer)
-march is used.
Curious enough, if CFLAGS contain -march=i686, the runtime will be built
both for i386 and i686. For any other value, only i386 variant will be
built.
Differential Revision: https://reviews.llvm.org/D26764
llvm-svn: 311842
The problem is that CMake is mostly imperative and the result of
processing "if (TARGET blah)" checks depends on the order of import of
CMake files.
In this case, "projects" folder is registered before "tools",
and calling "CheckClangHeaders" [renamed to have a better name]
errors out without even giving Clang a chance to be built.
This, in turn, leads to libFuzzer bot failures in some circumstances on
some machines (depends on whether LIT or UNIT tests are scheduled
first).
Differential Revision: https://reviews.llvm.org/D37126
llvm-svn: 311733
Resulting library binaries will be named libclang_rt.fuzzer*, and will
be placed in Clang toolchain, allowing redistribution.
Differential Revision: https://reviews.llvm.org/D36908
llvm-svn: 311407
CMake's add_custom_target is considered to be *always* out of date.
This patch changes it to a combination of add_custom_target and
add_custom_command which actually tracks dependencies' timestamps.
On my machine this reliably saves 6-7 seconds on each test group.
This can be a large difference when debugging small tests.
Differential Revision: https://reviews.llvm.org/D36912
llvm-svn: 311384
into a function.
Most CMake configuration under compiler-rt/lib/*/tests have
almost-the-same-but-not-quite functions of the form add_X_[unit]tests
for compiling and running the tests.
Much of the logic is duplicated with minor variations across different
sub-folders.
This can harm productivity for multiple reasons:
For newcomers, resulting CMake files are very large, hard to understand,
and hide the intention of the code.
Changes for enabling certain architectures end up being unnecessarily
large, as they get duplicated across multiple folders.
Adding new sub-projects requires more effort than it should, as a
developer has to again copy-n-paste the configuration, and it's not even
clear from which sub-project it should be copy-n-pasted.
With this change the logic of compile-and-generate-a-set-of-tests is
extracted into a function, which hopefully makes writing and reading
CMake much easier.
Differential Revision: https://reviews.llvm.org/D36116
llvm-svn: 310971
Detect ObjC files in `clang_compile` and pass an appropriate flag to a
compiler, also change `clang_compile` to a function.
Differential Revision: https://reviews.llvm.org/D36727
llvm-svn: 310945
Change macro to a function, and use a generic variable instead of
branching for handling multi-output build with
CMAKE_CONFIGURATION_TYPES.
Differential Revision: https://reviews.llvm.org/D36725
llvm-svn: 310944
Change macro to a function, move creating test directory into
`add_compiler_rt_test`.
Differential Revision: https://reviews.llvm.org/D36724
llvm-svn: 310943
Currently there's a large amount of CMake logic duplication for
compiling sanitizer tests.
If we add more sanitizers, the duplication will get even worse.
This change factors out common compilation commands into a macro
available to all sanitizers.
llvm-svn: 309405
This change adds support for compiler-rt builtins as an alternative
compiler runtime to libgcc.
Differential Revision: https://reviews.llvm.org/D35165
llvm-svn: 309361
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309341
This patch addresses two issues:
Most of the time, hacks with `if/else` in order to get support for
multi-configuration builds are superfluous.
The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it
expands to `.` on all single-configuration builds, and to a configuration
name otherwise.
The `if/else` hacks for the library name generation should also not be
done, as CMake has `TARGET_FILE` generator expression precisely for this
purpose, as it expands to the exact filename of the resulting target.
Differential Revision: https://reviews.llvm.org/D35952
llvm-svn: 309306
Aaron Smith