Commit Graph

1650 Commits

Author SHA1 Message Date
Stephen Neuendorffer 6701993027 [cmake] fix typo. 2020-05-13 17:42:46 -07:00
Stephen Neuendorffer 4f4b5b98a2 [cmake] Need PUBLIC dependencies for object targets even if LLVM_PTHREAD_LIB is unset
Fix logic in previous patch.
2020-05-13 17:19:32 -07:00
Stephen Neuendorffer 9ed9860d87 [cmake] Check for empty LLVM_PTHREAD_LIB
Windows builds broke because LLVM_THREAD_LIB is not set.
2020-05-13 16:42:05 -07:00
Stephen Neuendorffer 71ddc03a59 [cmake] Update creation of object library dependencies for LINK_LIBS PUBLIC (v2)
REGEX matching doesn't work here because the problematic library can
sometimes be "-lpthread" and sometimes "pthread".  Let's do the
simplest thing possible and just string compare.

Differential Revision: https://reviews.llvm.org/D79908
2020-05-13 14:18:21 -07:00
Stephen Neuendorffer 085234bedc [cmake] Update creation of object library dependencies for LINK_LIBS PUBLIC
We need to avoid declaring dependencies on strings which are valid
LINK_LIBS and not valid targets.  Previously, we used if(TARGET) to
check this condition.  However, if(TARGET) checks whether a target has
been created (in the cmake subdirectory traversal order) and not
whether it *will* be created.  This results in annoying directory
ordering problems.

This patch changes the check to more explicitly eliminate problematic
libraries (namely -lpthread) using a REGEX.

Differential Revision: https://reviews.llvm.org/D79837
2020-05-12 22:36:52 -07:00
Kirill Bobyrev 3bc9525731
[clangd] Fix remote index build for macOS with Homebrew-installed gRPC and Protobuf
Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D79387
2020-05-11 12:28:07 +02:00
Nico Weber c5647992e5 Remove a comment that is no longer true after d03838343f. 2020-05-10 20:15:29 -04:00
Nico Weber e3a4463446 Remove a variable write that is not needed after d03838343f. 2020-05-10 20:13:45 -04:00
David Tenty d26a8daa49 [AIX] Make sure we use export lists for plugins
Summary:
Besides just generating and consuming the lists, this includes:

 * Calling  nm with the right options in extract_symbols.py. Such as not
  demangling C++ names, which AIX nm does by default, and accepting both
  32/64-bit names.
 * Not having nm sort the list of symbols or we may run in to memory
   issues on debug builds, as nm calls a 32-bit sort.
 * Defaulting to having LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on for AIX
 * CMake versions prior to 3.16 set the -brtl linker flag globally on
   AIX. Clear it out early on so we don't run into failures. We will set
   it as needed.

Reviewers: jasonliu, DiggerLin, stevewan, hubert.reinterpretcast

Reviewed By: hubert.reinterpretcast

Subscribers: hubert.reinterpretcast, mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70972
2020-05-08 14:00:25 -04:00
Nico Weber d03838343f Make -Wnonportable-include-path ignore drive case on Windows.
See PR45812 for motivation.

No explicit test since I couldn't figure out how to get the
current disk drive in lower case into a form in lit where I could
mkdir it and cd to it. But the change does have test coverage in
that I can remove the case normalization in lit, and tests failed
on several bots (and for me locally if in a pwd with a lower-case
drive) without that normalization prior to this change.

Differential Revision: https://reviews.llvm.org/D79531
2020-05-07 15:54:09 -04:00
Stephen Neuendorffer a29f603ef0 [cmake] restrict object library dependency generation to PUBLIC libraries
Previous patch broken flang, which has some yet-to-be resolved cyclic
dependencies.   This patch fixes the breakage by restricting the dependencies
which are generated to public libraries, which is probably more sensible anyway.

Differential Revision: https://reviews.llvm.org/D79366
2020-05-04 14:12:42 -07:00
Stephen Neuendorffer 8303b1f46a [cmake] Ensure that LINK_LIBS are dependencies for object library targets
In MLIR, it is common for automatically generated headers to be included
in many places.  To avoid tracking these dependencies explicitly in
cmake, they are treated as part of a library which 'owns' the generated
header.  Users of the generated header link against the owning library.
However, object libraries don't actually 'link', so this dependence gets
lost.  This patch adds an explicit dependence for these generated headers
when creating object library targets to ensure that generated headers
are appropriately generated

Differential Revision: https://reviews.llvm.org/D79241
2020-05-04 08:45:53 -07:00
Vladimir Vereschaka cad1cbc4bc [CMake] Provide a proper default location for llvm-lit for out-of-tree users on Windows host.
llvm-lit gets '.py' extension on Windows host during its configuration.
We need to provide a correct name for llvm-lit including file extension
within LLVM_CONFIG_DEFAULT_EXTERNAL_LIT variable.

Update for commit 45526d29a5.

Differential Revision: https://reviews.llvm.org/D79144
2020-05-01 11:48:30 -07:00
Sebastian Neubauer 1dbb7a3518 [CMake] Fix cross-compiling with LLVM as CMake subproject
When embedding LLVM as a CMake subproject, using cross-compiling does
not work at the moment. This also affects -DLLVM_OPTIMIZED_TABLEGEN=1,
which uses the same CMake infrastructure.

This patch replaces global CMake variables with the current version,
which allows cross-compilation to work in a subproject.

CMAKE_BINARY_DIR -> CMAKE_CURRENT_BINARY_DIR
CMAKE_SOURCE_DIR -> CMAKE_CURRENT_SOURCE_DIR
CMAKE_PROJECT_NAME -> PROJECT_NAME

Differential Revision: https://reviews.llvm.org/D78913
2020-04-30 16:54:20 +02:00
serge-sans-paille 37309fb02f Fix spurious warning in ExtensionDependencies.inc [nfc] 2020-04-30 11:16:37 +02:00
Saleem Abdulrasool 216833b32b Revert "Temporarily revert "build: use `find_package(Python3)` if available""
This reverts commit 35edd704e0.

Revert the revert and extend the patch further to account for the use of
the `PYTHONINTERP_FOUND`.
2020-04-29 01:38:08 +00:00
Eric Christopher 35edd704e0 Temporarily revert "build: use `find_package(Python3)` if available"
as it seems to be causing multiple people problems with running tests
and building.

This reverts commit c4c3883b00.
2020-04-28 16:41:22 -07:00
Reid Kleckner b8000c0ce8 [Windows] Autolink with basenames and add libdir to libpath
Prior to this change, for a few compiler-rt libraries such as ubsan and
the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib"
into the .drective section of every object compiled with
-finstr-profile-generate or -fsanitize=ubsan as appropriate.

These paths assume that the link step will run from the same working
directory as the compile step. There is also evidence that sometimes the
paths become absolute, such as when clang is run from a different drive
letter from the current working directory. This is fragile, and I'd like
to get away from having paths embedded in the object if possible. Long
ago it was suggested that we use this for ASan, and apparently I felt
the same way back then:
https://reviews.llvm.org/D4428#56536

This is also consistent with how all other autolinking usage works for
PS4, Mac, and Windows: they all use basenames, not paths.

To keep things working for people using the standard GCC driver
workflow, the driver now adds the resource directory to the linker
library search path when it calls the linker. This is enough to make
check-ubsan pass, and seems like a generally good thing.

Users that invoke the linker directly (most clang-cl users) will have to
add clang's resource library directory to their linker search path in
their build system. I'm not sure where I can document this. Ideally I'd
also do it in the MSBuild files, but I can't figure out where they go.
I'd like to start with this for now.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D65543
2020-04-28 11:36:21 -07:00
Kirill Bobyrev 9ff3f339e8
[clangd] Fix remote index build without shared libs mode
Summary:
Generated Protobuf library has to be in CLANG_EXPORTS and should also be
installed appropriately. The easiest way to do that is via CMake's
add_clang_library. That unfortunately applies "one directory - one
clang_(library|tool)" policy so .proto files should be in a separate directory
and complicates the layout.

This setup works both in shared and static libs mode.

Resolves: https://github.com/clangd/clangd/issues/351

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits, llvm-commits

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D78885
2020-04-28 19:16:37 +02:00
Saleem Abdulrasool c4c3883b00 build: use `find_package(Python3)` if available
This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
2020-04-28 09:24:27 -07:00
serge-sans-paille e849e7a700 Use components instead of libraries in Polly linkage step
As a side effect, this tests (and fix a bug) in the compiler extension handling
of components.

Differential Revision: https://reviews.llvm.org/D78358
2020-04-28 09:44:10 +02:00
Saleem Abdulrasool be884b7935 Revert "build: use `find_package(Python3)` if available"
This reverts commit cd84bfb814.  Although
this passed the CI in phabricator, some of the bots are missing python3
packages, revert it temporarily.
2020-04-27 20:03:32 -07:00
Saleem Abdulrasool cd84bfb814 build: use `find_package(Python3)` if available
This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
2020-04-28 01:33:10 +00:00
serge-sans-paille e307eeba01 Do not declare compiler extension member as const
It keeps them default constructible.
2020-04-24 11:44:42 +02:00
serge-sans-paille 8f766e382b Update compiler extension integration into the build system
The approach here is to create a new (empty) component, `Extensions', where all
statically compiled extensions dynamically register their dependencies. That way
we're more natively compatible with LLVMBuild and llvm-config.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=44870

Differential Revision: https://reviews.llvm.org/D78192
2020-04-24 09:40:14 +02:00
Stephen Neuendorffer 45526d29a5 [CMAKE] Provide default location for llvm-lit for out-of-tree users.
Several external build users contain some heuristics for finding llvm-lit.
There are several cases we need to worry about:
- External builds against a build tree (with LLVM_BUILD_UTILS)
- External builds against an install tree (with LLMV_BUILD_UTIL
  and LLVM_INSTALL_UTILS)
- External builds against some location which doesn't have an
  llvm-lit, but llvm-lit is available through some other means, such
  as an available source tree, or a packager provided llvm-lit.

For the third case, LLVM_EXTERNAL_LIT suffices, but in other cases
there's no standard way to find llvm-lit.  It seems like each user
cooks their own heuristics:

- clang tries to look in the LLVM source tree, and failing that falls
  back to looking for a packaged llvm-lit.
- libcxx tries to look in the LLVM source tree, which might come from
  llvm-config or be explicitly specified.

This patch is a first stop to solving this by providing a default location
for llvm-lit using LLVM_DEFAULT_EXTERNAL_LIT.  The expectation is that
future patches can clean up users like clang and libcxx to rely
on this mechanism for out-of-tree builds.

Differential Revision: https://reviews.llvm.org/D77110
2020-04-22 15:13:23 -07:00
Zola Bridges 0f12480bd1 [dfsan] Add "DataFlow" option to LLVM_USE_SANITIZER
Summary:
This patch add the dataflow option to LLVM_USE_SANITIZER and documents
it.

Tested via check-cxx (wip to fix the errors).

Reviewers: morehouse, #libc!

Subscribers: mgorny, cfe-commits, libcxx-commits

Tags: #clang, #libc

Differential Revision: https://reviews.llvm.org/D78390
2020-04-20 10:30:52 -07:00
serge-sans-paille f44a508df6 [nfc] Cleanup extension header generation 2020-04-20 14:44:34 +02:00
Fangrui Song 041a3557f0 [CMake] Delete HAVE_SCHED_GETAFFINITY and HAVE_CPU_COUNT
sched_getaffinity (Linux specific) has been available

* in glibc since 2002-08-08 (commit 972e719e8154eec5f543b027e2a08dfa285d55d5)
* in musl since the initial check-in.
2020-04-19 08:50:23 -07:00
Luís Marques a348de480d [CMake][NFC] Clean up CheckAtomic.cmake
`CheckAtomic.cmake` was skipping the test of whether atomics work in MSVC
without an atomics library (they do), but not setting the value of
`HAVE_CXX_ATOMICS_WITHOUT_LIB`. That caused build issues when trying to land
D69869. I fixed that issue in f128f442a3, by adding an `elseif(MSVC)`, as
was being done below in the 64-bit atomics check. That minimal fix did work,
but it kept various inconsistencies between the original atomics check and
the 64-bit one. This patch now makes the checks follow the same structure,
cleaning them up.

Differential Revision: https://reviews.llvm.org/D74767
2020-04-18 12:53:22 +01:00
Eli Friedman 4623c2ffa4 Fix interaction of static plugins with -DLLVM_LINK_LLVM_DYLIB=ON.
We should link static plugins into libLLVM.so; they shouldn't depend on
libLLVM.so.

Fixes https://bugs.llvm.org/show_bug.cgi?id=45571

Differential Revision: https://reviews.llvm.org/D78332
2020-04-17 11:49:05 -07:00
Kirill Bobyrev cee80c0489 [clangd] Pull installed gRPC and introduce clangd-remote-(server|client)
Summary:
This patch allows using installed gRPC to build two simple tools which
currently provide the functionality of looking up the symbol by name.
remote-index-client is a simplified version of dexp which connects to
remote-index-server passes lookup requests.

I also significantly reduced the scope of this patch to prevent large changelist
and more bugs. The next steps would be:

* Extending Protocol for deep copies of Symbol and inherit RemoteIndex from
  Index to unify the interfaces
* Make remote-index-server more generic and merge the remote index client with
  dexp
* Modify Clangd to allow using remote index instead of the local one for all
  global index requests

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77794
2020-04-16 13:55:08 +02:00
Nico Weber b9fd375d75 Revert "[lit] Keep original cfg file case around."
This reverts commit bc3f54de18.

The patch breaks in the following two scenarios:

1. When manually passing an absolute path to llvm-lit with a lower-case
   drive letter: `python bin\llvm-lit.py -sv c:\llvm-project\clang\test\PCH`

2. When the PWD has a lower-case drive letter, like after running
   `cd c:\` with a lower-case "c:" (cmd's default is upper-case, but
   it takes case-ness from what's passed to `cd` apparently).
2020-04-15 17:19:39 -04:00
Nico Weber bc3f54de18 [lit] Keep original cfg file case around.
There's been some back and forth if the cfg paths in the
config_map should be normcase()d. The argument for is that
it allows using all-lower spelling in cmd on Windows, the
argument against that doing so is lossy.

Before the relative-paths-in-generated-lit.site.cfg.py work,
there was no downside to calling normcase(), but with it
we need a hack to recover the original case.

This time, normcase() the hashtable key, but store the original
cased key in addition to the value. This fixes both cons, at the
cost of a few bytes more memory.

Differential Revision: https://reviews.llvm.org/D78169
2020-04-15 14:18:11 -04:00
Nico Weber 4d4fef22da Revert a few unsuccessful attempts at fixing bots.
I broke bots last week and tried a few things to fix them.
These were attempts that didn't help, so back them back out.

This reverts commit c7aff9a109.
This reverts commit 8838d6d356.
This reverts commit e875ba1509.
2020-04-13 17:09:21 -04:00
Balazs Benics 45ab67721e [NFC] Fix Z3 version detection regexp
Summary:
We use the `major.minor.build` version format in this file, except when we try
to parse the result of the test binary.
In that regular expression, we expect the `major.minor.build.rev` format, which
is never fulfilled.

Reviewers: NoQ, george.karpenkov, alexandre.isoard, serge-sans-paille

Reviewed By: NoQ

Subscribers: mgorny, mikhail.ramalho, Charusso, martong, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76837
2020-04-09 13:06:22 +02:00
Nico Weber d4638cbad7 Make paths in generated llvm-lit relative as well.
This builds on top of D77184. With this, I can rename my build directory
to a different name and `bin/llvm-lit ../llvm-project/clang/test
../llvm-project/llvm/test` still succeeds.

I haven't tried copying the build dir to a different machine to run
tests there yet, but I tried something like it a few months ago and it
worked back then.

Changes:
- Make configure_lit_site_cfg() store the main / generated config pair
  interleaved in the LLVM_LIT_CONFIG_FILES list and postpone converting
  it to python code to llvm-lit's CMakeList.
- Pull the relpath code into a new function make_paths_relative() and
  call that in llvm-lit's CMakeList, prior to converting the list to
  python code.
- Pull the path() function into a variable and use that in llvm-lit's
  CMakeList too.

Differential Revision: https://reviews.llvm.org/D77496
2020-04-06 09:18:23 -04:00
Nico Weber 7db64e202f Disable relative paths in lit.site.cfg in presence of symlinks
See https://reviews.llvm.org/D77184#1961208
2020-04-04 12:35:40 -04:00
Nico Weber 18a18b2001 Fix standalone clang builds after fb80b6b2d5.
When clang is built against a prebuilt LLVM, LLVM_SOURCE_DIR is
empty, which due to a cmake quirk caused list lengths to get out
of sync. Add a workaround.
2020-04-03 17:15:09 -04:00
Andrew Ng dbb0d8ecb3 Don't use relpaths in lit cfg if build/source dir are on different drives.
See discussion on https://reviews.llvm.org/D77184.
2020-04-03 15:43:50 -04:00
Stephen Neuendorffer 0c0831f74b [CMAKE] Plumb include_directories() into tablegen()
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths.  This
becomes unwieldy as there are more users for which these paths are
insufficient.  For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen.  As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().

I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful.  There are several users in clang which apparently
don't have the current directory as an include_directories().  This could
be considered separately.

The new version of this path uses list APPEND rather than list TRANSFORM,
in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then
we can use list TRANSFORM instead.

Differential Revision: https://reviews.llvm.org/D77156
2020-04-03 11:23:38 -07:00
Stephen Neuendorffer f288c21687 Revert "[CMAKE] Plumb include_directories() into tablegen()"
This reverts commit ae044c5b0c.

This breaks the buildbots, which use an older version of cmake.
2020-04-03 10:47:36 -07:00
Stephen Neuendorffer ae044c5b0c [CMAKE] Plumb include_directories() into tablegen()
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths.  This
becomes unwieldy as there are more users for which these paths are
insufficient.  For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen.  As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().

I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful.  There are several users in clang which apparently
don't have the current directory as an include_directories().  This could
be considered separately.

Differential Revision: https://reviews.llvm.org/D77156
2020-04-03 10:38:25 -07:00
Nico Weber 20cb7a904f This might actually fix the Windows bots after a16ba6fea. 2020-04-02 22:22:54 -04:00
Nico Weber c7aff9a109 another wild guess at the win bot-only failures 2020-04-02 21:23:05 -04:00
Nico Weber 8838d6d356 try more to appease win bots 2020-04-02 20:27:31 -04:00
Nico Weber e875ba1509 Try again to get tests passing again on Windows.
Things pass locally, but some tests on some bots are still unhappy.
I'm not sure why. See if using forward slashes as before helps.
2020-04-02 20:00:38 -04:00
Nico Weber a16ba6fea2 Reland "Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang"
The problem on Windows was that the \b in "..\bin" was interpreted
as an escape sequence. Use r"" strings to prevent that.

This reverts commit ab11b9eefa,
with raw strings in the lit.site.cfg.py.in files.

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 16:12:03 -04:00
Nico Weber ab11b9eefa Revert "Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang"
This reverts commit fb80b6b2d5 and
follow-up 631ee8b24a.

Seems to not work on Windows:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/31684
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/6512

Let's revert while I investigate.
2020-04-02 15:00:09 -04:00
Nico Weber 631ee8b24a Make fb80b6b2d5 actually work.
I broke it with last-minute changes right before committing.

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 14:28:34 -04:00