After D80096, bots that build clang for distribution and that can't use
system gcc / libstdc++ need to pass a working rpath so that unit test
binaries can run. The method suggested in GettingStarted.rst works fine
for local development, but it results in an absolute local rpath ending
up even in distributed binaries like clang, which is both ugly and
unnecessary.
Add an explicit toggle that can be used to add an rpath only for the
non-distributed binaries that need it.
Differential Revision: https://reviews.llvm.org/D80534
We want to make sure that LINKER_IS_LLD_LINK is properly set - in
this case it shouldn't be set when building for MinGW.
Then we want to make the test for it correct and finally include
the option to build with thinlto cache since the MinGW driver now
supports that.
Differential Revision: https://reviews.llvm.org/D80493
Summary:
The `-bcdtors:mbr` option causes processing for constructors and
destructors to omit otherwise-unreferenced members of static libraries,
matching the processing done on Linux, where `--whole-archive` is not
the default. Applying this option is desirable for reducing the
footprint of an installation.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D79749
Omitting comments can make the output much smaller. Size/time impact on
my machine:
* lib/Target/AArch64/AArch64GenDAGISel.inc, 10MiB (8.89s) -> 5MiB (3.20s)
* lib/Target/X86/X86GenDAGISel.inc, 20MiB (6.48s) -> 8.5MiB (4.18s)
In total, this change decreases lib/Target/*/*GenDAGISel.inc from
71.4MiB to 30.1MiB.
As rnk suggested, we can consider an option next to LLVM_OPTIMIZED_TABLEGEN
once we have more needs like this.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D78884
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
`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
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
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).
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
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.
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
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
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.
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
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
Nico Weber