Commit Graph

1337 Commits

Author SHA1 Message Date
Lion Yang
023adc2eda Test commit access
Remove trailing spaces

llvm-svn: 342268
2018-09-14 19:43:11 +00:00
Nico Weber
5f1a463b19 Introduce explicit add_unittest_with_input_files target for tests that use llvm::getInputFileDirectory()
Using llvm::getInputFileDirectory() in unit tests is discouraged, so require an explicit opt-in.
This way, cmake also writes ~60 fewer unused files to disk.

Differential Revision: https://reviews.llvm.org/D52095

llvm-svn: 342248
2018-09-14 17:34:46 +00:00
Alexandre Ganea
8d999aab74 [CMake] Fix LLVM_ENABLE_LTO option on Windows
Differential Revision: https://reviews.llvm.org/D51804

llvm-svn: 341701
2018-09-07 20:07:36 +00:00
Zachary Turner
9454b327ad Fix a configure issue with Visual Studio generators.
We can't put the unittest source dir map in the configuration
specific directory because VS doesn't have a configure-specific
directory, instead it only knows this at runtime.  So we have
to remove this from the path.  This in turn means that the path
will be slightly different in VS configurations vs non vs
configurations.  In the former, the source map will be in the
parent directory of the executable, and in the latter it will
be in the same directory as the executable.  So check both.

llvm-svn: 341590
2018-09-06 22:00:38 +00:00
Zachary Turner
8f68390df4 Add support for unittest inputs.
Occasionally it is useful to have unittest which take inputs.
While we normally try to have this test be more of a lit test
we occasionally don't have tools that can exercise the code
in the right way to test certain things.  LLDB has been using
this style of unit test for a while, particularly with regards
to how it tests core dump and minidump file parsing.  Recently
i needed this as well for the case where we want to test that
some of the PDB reading code works correctly.  It needs to
exercise the code in a way that is not covered by any dumper
and would be impractical to implement in one of the dumpers,
but requires a valid PDB file.  Since this is now needed by
more than one project, it makes sense to have this be a
generally supported thing that unit tests can do, and we just
encourage people to use this sparingly.

Differential Revision: https://reviews.llvm.org/D51561

llvm-svn: 341502
2018-09-05 23:30:17 +00:00
Aaron Ballman
a55f327dae Disable -Wnoexcept-type due to false positives with GCC.
GCC triggers false positives if a nothrow function is called through a template argument. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80985 for details. The LLVM libraries have no stable C++ API, so the warning is not useful.

llvm-svn: 341361
2018-09-04 12:03:49 +00:00
Nico Weber
c7dc6a354b Remove LIT_SITE_CFG_IN_FOOTER, llvm
It's always replaced with the same (short) static string, so just put that
there directly.

No intended behavior change.
https://reviews.llvm.org/D51357

llvm-svn: 341135
2018-08-30 22:13:34 +00:00
Roman Lebedev
3ff355fa36 Revert "[CMake] Use LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES"
That resulted in the check-llvm-* targets not being avaliable
in the QtCreator-configured build directories.

Moreover, that was a clearly non-NFC change, and i can't find any review
for it.

This reverts commit rL340435.

llvm-svn: 341045
2018-08-30 09:32:09 +00:00
Kirill Bobyrev
0f55045526 Pull google/benchmark library to the LLVM tree
This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.

The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:

* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
  targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
  benchmark targets to the list of default LLVM targets (i.e. if `ON`
  benchmarks will be built upon standard build invocation, e.g. `ninja` or
  `make` with no specific targets)

List of modifications:

* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled

Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html

Reviewed by: dberris, lebedev.ri

Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits

Differential Revision: https://reviews.llvm.org/D50894

llvm-svn: 340809
2018-08-28 09:42:41 +00:00
Chris Bieneman
fde8ce5023 [CMake] Use LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES
There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.

This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.

With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.

llvm-svn: 340435
2018-08-22 18:40:24 +00:00
Hans Wennborg
f4be62b408 [cmake] Prevent LLVMgold.so from being unloaded on Linux
Extend the fix from D40459 to also apply to modules such as the LLVM
gold plugin. This is needed because current binutils master (and future
binutils 2.32) calls dlclose() on bfd plugins as part of a recent fix
for https://sourceware.org/bugzilla/show_bug.cgi?id=23460.

Patch by Evangelos Foutras!

Differential Revision: https://reviews.llvm.org/D50416

llvm-svn: 339883
2018-08-16 15:12:12 +00:00
Petr Hosek
0c06d55837 [CMake] Split -gx strip flag into -g -x
llvm-strip doesn't handle -gx spelling, so we need to split these
as two separate flags.

Differential Revision: https://reviews.llvm.org/D50684

llvm-svn: 339639
2018-08-14 02:00:21 +00:00
Petr Hosek
1cfc2ea35f [CMake] Use normalized Windows target triples
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.

Differential Revision: https://reviews.llvm.org/D47381

llvm-svn: 339307
2018-08-09 02:16:18 +00:00
Michal Gorny
6403c39fa3 [cmake] Append LLVM_VERSION_SUFFIX to SOVERSION
Append LLVM_VERSION_SUFFIX to SOVERSION. This makes it possible
to use the suffix to differentiate binary-incompatible versions
of LLVM built via BUILD_SHARED_LIBS.

We are planning to use this to temporarily preserve ABI-incompatible
variants of LLVM while switching the system between them, e.g. when
rebuilding the system to use libc++. Normally this would mean that once
LLVM is rebuilt using libc++ all the reverse dependencies become
immediately broken. Using a distinct SOVERSION allows us to preserve
the ABI compatibility before all the packages are rebuilt.

Differential Revision: https://reviews.llvm.org/D39939

llvm-svn: 339286
2018-08-08 20:45:03 +00:00
Michal Gorny
fe3269a360 cmake: Store LLVM_VERSION_SUFFIX in LLVMConfig.cmake
Store LLVM_VERSION_SUFFIX along with other version components
in LLVMConfig.cmake. This fixes preserving the suffix set while building
LLVM to stand-alone builds of other components, e.g. clang,
and therefore improves uniformity between the two build models.

Given that there is no apparent reason to omit this part of version,
that it is distributed to subprojects when building as part of LLVM
and that it is included in LLVM_PACKAGE_VERSION, I think it was omitted
accidentally rather than done on purpose.

Differential Revision: https://reviews.llvm.org/D43701

llvm-svn: 339285
2018-08-08 20:44:58 +00:00
Hans Wennborg
bdae10300d Add llvm-rc to LLVM_TOOLCHAIN_TOOLS (PR38386)
This means it will be installed also in builds configured with
LLVM_INSTALL_TOOLCHAIN_ONLY, such as the Windows packages.

llvm-svn: 338495
2018-08-01 07:51:55 +00:00
Philip Pfaffe
64e5222c0d [CMake] Followup for r337366: Only export LLVM_LINK_LLVM_DYLIB if it's set to ON
Summary:
As it was, always exporting LLVM_LINK_LLVM_DYLIB caused out-of-tree
clients to lose the ability to link against the dylib, even if in-tree tools did
not. By only exporting the setting if it is enabled, out-of-tree clients get the
correct default, but may still choose if they can.

Reviewers: mgorny, beanz, labath, bogner, chandlerc

Reviewed By: bogner, chandlerc

Subscribers: bollu, llvm-commits

Differential Revision: https://reviews.llvm.org/D49843

llvm-svn: 338119
2018-07-27 10:57:51 +00:00
Florian Hahn
82faed36eb [UBSan] Also use blacklist for 'Address; Undefined' setting
It looks like currently the UBSan blacklist is only applied when "Undefined" is selected.
This patch updates the cmake file to apply it whenever Undefined is selected
 (e.g. 'Address; Undefined' ). This  allows us to use the workaround added in
rL335525 when using AddressSan and UBSan together.

Reviewers: eugenis, vitalybuka

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D49558

llvm-svn: 337539
2018-07-20 10:12:31 +00:00
Reid Kleckner
a446bf556d Disable GCC's -Wclass-memaccess warning
It fires on things like SmallVector<std::pair<int, int>>, where we
intentionally use memcpy instead of calling the assignment operator.
This warning fires in practically every LLVM TU, so we have to do
something about it, even if we aren't interested in being 100% warning
clean with GCC.

Reported as PR37337

llvm-svn: 337492
2018-07-19 20:14:46 +00:00
Philip Pfaffe
1002ce3706 [CMake] Export the LLVM_LINK_LLVM_DYLIB setting
Summary:
When building out-of-tree tools, there are several macros available to
automate linking against llvm. An examples is `add_llvm_executable`, or
the clang variant of this.

These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether to
link against libraries defined by setting LLVM_LINK_COMPONENTS or to
link against libLLVM instead. Currently this is problematic in
out-of-tree targets, because they cannot identify whether this option is
required or even available. If the option was enabled in LLVM's own
build, the clang libraries are built against libLLVM, so a client
linking against those must link against it too. On the other hand the
client can't just always link against it, because it might not be
available.

This is related to D44391, but that change assumed the client knew
whether they wanted the dylib or not.

Reviewers: mgorny, beanz, labath

Reviewed By: mgorny

Subscribers: bollu, llvm-commits

Differential Revision: https://reviews.llvm.org/D49193

llvm-svn: 337366
2018-07-18 08:53:31 +00:00
Petr Hosek
ee815080e6 [CMake] Pass CMAKE_INSTALL_DO_STRIP to external projects
This is necessary to make install-<target>-stripped work for
external projects such as runtimes.

Differential Revision: https://reviews.llvm.org/D49335

llvm-svn: 337115
2018-07-15 02:12:25 +00:00
Justin Bogner
d3016d423d [CMake] Teach the build system to codesign built products
Automatically codesign all executables and dynamic libraries if a
codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This
option is darwin only for now.

Also update platforms/iOS.cmake to pick up the right versions of
codesign and codesign_allocate.

llvm-svn: 336708
2018-07-10 17:32:48 +00:00
Filipe Cabecinhas
549730082d [cmake] Change WIN32 test to CMAKE_HOST_WIN32
The test is about what can be run on the host, not the cmake target.
When cross-compiling (compiler-rt at least) on Windows, we end up with
lit being unable to run llvm-lit because it can't find the llvm-lit
module.

llvm-svn: 335961
2018-06-29 10:34:37 +00:00
Justin Bogner
fa021a2fac [CMake] Respect CMAKE_STRIP and CMAKE_DSYMUTIL on apple platforms
This allows overriding the strip and dsymutil tools, and updates
iOS.cmake to do so. I've also added libtool to iOS.cmake, but it was
already respecting CMAKE_LIBTOOL if set.

llvm-svn: 335900
2018-06-28 18:36:52 +00:00
Petr Hosek
4f4061d600 [CMake] Use variables rather than ":" delimiters
This is a more idiomatic CMake.

Differential Revision: https://reviews.llvm.org/D37644

llvm-svn: 335703
2018-06-27 03:14:41 +00:00
Brad Smith
8ca02f1807 [CMake] Do not use --gc-sections on OpenBSD
llvm-svn: 335425
2018-06-23 21:43:27 +00:00
Shoaib Meenai
00e5a5e3bd [cmake] Change ON/OFF to YES/NO. NFC
compnerd pointed out that the latter reads better over here.

llvm-svn: 334781
2018-06-14 23:40:04 +00:00
Shoaib Meenai
4ae4788876 [cmake] Add linker detection for Apple platforms
LLVM currently assumes that Apple platforms will always use ld64. In the
future, LLD Mach-O might also be supported, so add the beginnings of
linker detection support. ld64 is currently the only detected linker,
since `ld64.lld -v` doesn't yield any useful version output, but we can
add that detection later, and in the meantime it's still useful to have
the ld64 identification.

Switch clang's order file check to use this new detection rather than
just checking for the presence of an ld64 executable.

Differential Revision: https://reviews.llvm.org/D48201

llvm-svn: 334780
2018-06-14 23:26:33 +00:00
Bruno Cardoso Lopes
11b4351a5f [CMAKE] Honor CMAKE_OSX_SYSROOT to compute include dir for libxml2
On MacOS, if CMAKE_OSX_SYSROOT is used and the user has command line tools
installed, we currently get the include path for libxml2 as
/usr/include/libxml2, instead of ${CMAKE_OSX_SYSROOT}/usr/include/libxml2.

Make it consistent on MacOS by prefixing ${CMAKE_OSX_SYSROOT} when
possible.

rdar://problem/41103601

llvm-svn: 334746
2018-06-14 18:19:54 +00:00
Petr Hosek
2480179bdd [CMake] Pass additional CMake tools to external projects
This is needed when the external projects try to use other tools
besides just the compiler and the linker.

Differential Revision: https://reviews.llvm.org/D47833

llvm-svn: 334136
2018-06-06 21:43:37 +00:00
Pavel Labath
e0e9132081 [cmake] fix a typo in llvm_config macro
Summary:
The macro parses out the USE_SHARED option out of the argument list, but
then ignores it and accesses the variable with the same name instead. It
seems the intention here was to check the argument value.

Technically, this is NFC, because the only in-tree usage
(add_llvm_executable) of USE_SHARED sets both the variable and the
argument when calling llvm_config, but it makes the usage of this macro
for out-of-tree users more sensible.

Reviewers: mgorny, beanz

Reviewed By: mgorny

Subscribers: foutrelis, llvm-commits

Differential Revision: https://reviews.llvm.org/D44420

llvm-svn: 334082
2018-06-06 10:07:08 +00:00
Nico Weber
4d14352f33 Use -Wextra spelling instead of -W
No difference in behavior, but a bit easier to search for.
https://reviews.llvm.org/D47490

llvm-svn: 333651
2018-05-31 13:41:04 +00:00
Reid Kleckner
fd0e6cf515 Remove CMake workaround for LLD PR24476 which is no longer needed
llvm-svn: 332880
2018-05-21 20:14:46 +00:00
Nico Weber
51d6701090 Revert 332750, llvm part (see comment on D46910).
llvm-svn: 332823
2018-05-20 23:03:17 +00:00
Vassil Vassilev
d9088961cc [cmake] Add a switch to enable/disable bindings.
Differential Revision: https://reviews.llvm.org/D42026

llvm-svn: 332816
2018-05-20 08:37:54 +00:00
Nico Weber
53628c120e Enable colored diagnostics in ninja builds when building with gcc 4.9+.
GCC has supported -fdiagnostics-color since 4.9.

https://reviews.llvm.org/D47083

llvm-svn: 332793
2018-05-19 02:36:27 +00:00
Petr Hosek
5f84b3720a [Support] Avoid normalization in sys::getDefaultTargetTriple
The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.

Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.

Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.

Differential Revision: https://reviews.llvm.org/D46910

llvm-svn: 332750
2018-05-18 18:33:07 +00:00
Chris Bieneman
c8ad1f12f2 [CMake] Make optimizing sanitizer builds optional
This behavior has been the default for a long time, so the default value is On, however this can make it difficult to debug sanitizer failures, so we should have an option to turn it off.

llvm-svn: 332628
2018-05-17 16:55:29 +00:00
Petr Hosek
a12eb6a357 [CMake] Use CMAKE_OBJCOPY and CMAKE_STRIP to externalize debug info
Don't hardcode objcopy and strip names, rather use CMAKE_OBJCOPY and
CMAKE_STRIP variables which allows users to override the tools used
such as using llvm-objcopy and llvm-strip instead of binutils versions.

Differential Revision: https://reviews.llvm.org/D46611

llvm-svn: 331827
2018-05-09 00:07:42 +00:00
Chandler Carruth
5b6b9b3232 Revert r330742: Let TableGen write output only if it changed, instead of doing so in cmake.
This change causes us to re-run tablegen for every single target on
every single build. This is much, much worse than the problem being
fixed AFAICT.

On my system, it makes a clean rebuild of `llc` with nothing changed go
from .5s to over 8s. On systems with less parallelism, slower file
systems, or high process startup overhead this will be even more
extreme.

The only way I see this could be a win is in clean builds where we churn
the filesystem. But I think incremental rebuild is more important, and
so if we want to re-instate this, it needs to be done in a way that
doesn't trigger constant re-runs of tablegen.

llvm-svn: 331702
2018-05-07 23:41:48 +00:00
Petr Hosek
8259fee6a9 [Support] Support building LLVM for Fuchsia
These are necessary changes to support building LLVM for Fuchsia.
While these are not sufficient to run on Fuchsia, they are still
useful when cross-compiling LLVM libraries and runtimes for Fuchsia.

Differential Revision: https://reviews.llvm.org/D46345

llvm-svn: 331423
2018-05-03 01:38:49 +00:00
Nico Weber
da42110efc Stop setting LLVM_ON_WIN32 in config.h and llvm-config.h.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.

I replaced all uses of LLVM_ON_WIN32 with _WIN32 in r331127 (llvm),
r331069 (clang), r329697 (lldb), r329696 (lld), r329696 (clang-tools-extra).

If your out-of-tree program used LLVM_ON_WIN32, just use _WIN32 instead, which
is set at exactly the same time to exactly the same value.

https://reviews.llvm.org/D46264

llvm-svn: 331224
2018-04-30 20:19:48 +00:00
Shoaib Meenai
2b5151e0b0 [cmake] Make linker detection take flags into account
LLVM might be compiled using a toolchain file which controls the linker
to use via flags (e.g. `-B` or `-fuse-ld=`). Take these flags into
account for linker detection. We can also correct the detection by
manually passing LLVM_USE_LINKER, of course, but it seems more
convenient to have the detection take flags into account.

Differential Revision: https://reviews.llvm.org/D45464

llvm-svn: 330924
2018-04-26 06:04:46 +00:00
Nico Weber
4377f43d2b Rename Attributes.gen, Intrinsics.gen to Attributes.inc, Intrinsics.inc
Virtually all other tablegen outputs are called .inc, not .gen, so rename these two too for consistency.
No behavior change.

https://reviews.llvm.org/D46058

llvm-svn: 330843
2018-04-25 17:07:46 +00:00
Shoaib Meenai
8601096ed0 [cmake] Fix libc++ detection
-stdlib=libc++ is added to both the compilation and the link flags, but
the logic for adding it was only checking if it was supported during
compilation and not linking. This could lead to false positives, for
example when using clang with libstdc++ (where the compiler would
support -stdlib=libc++ but then linking would fail because of libc++
actually being unavailable).

llvm-svn: 330761
2018-04-24 19:47:39 +00:00
Nico Weber
c47070a3d3 Let TableGen write output only if it changed, instead of doing so in cmake.
Removes one subprocess and one temp file from the build for each tablegen
invocation.

No intended behavior change.

https://reviews.llvm.org/D45899

llvm-svn: 330742
2018-04-24 17:29:05 +00:00
Pavel Labath
95b9d71eef [cmake] Improve pthread_[gs]etname_np detection code
Summary:
Due to some android peculiarities, in some build configurations
(statically linked executables targeting older releases) we could detect
the presence of these functions (because they are present in libc.a,
where check_library_exists searches), but then fail to build because the
headers did not include the definition.

This attempts to remedy that by upgrading the check_library_exists to
check_symbol_exists, which will check that the function is declared too.

I am hoping that a more thorough check will make the messy #ifdef we
have accumulated in the code obsolete, so I optimistically try to remove
them.

Reviewers: zturner, kparzysz, danalbert

Subscribers: srhines, mgorny, krytarowski, llvm-commits

Differential Revision: https://reviews.llvm.org/D45359

llvm-svn: 330251
2018-04-18 13:13:27 +00:00
Saleem Abdulrasool
d583a0f050 Revert "build: reserve --color-diagnostics for lld"
This reverts SVN r330158.

Seems that there was a change to linker flags handling in SVN r316972.
That would alter the behaviour to correct the linker flag handling in
CMake (requiring CMake 3.4.3+).  Since that is already the minimum
version required for LLVM, hard coding the knowledge of the linker is
not required, which is a strictly better solution.

llvm-svn: 330161
2018-04-16 21:57:10 +00:00
Saleem Abdulrasool
1511d68d24 build: reserve --color-diagnostics for lld
When building out-of-tree compilers (e.g. swift), the linker check here
may yield incorrect values.  Ensure that we are using lld before we
attempt to use `--color-diagnostics` for the linker.  Other linkers (i.e
bfd, gold) do not support this flag and the test can pass in some cases
and then fail subsequently when building.

llvm-svn: 330158
2018-04-16 21:05:56 +00:00
Clement Courbet
512991d3bb [Build][NFC] Split off libpfm detection to a separate module.
llvm-svn: 329783
2018-04-11 07:39:00 +00:00