The issue with LLVM_ENABLE_LLD is that it just passes -fuse-ld=lld
to compiler/linker options which makes sense only for those platforms
where cmake invokes a compiler driver for linking. On Windows (MSVC) cmake
invokes the linker directly and requires CMAKE_LINKER to be specified
otherwise it defaults CMAKE_LINKER to be link.exe.
This patch allows BOOTSTRAP_LLVM_ENABLE_LLD to set CMAKE_LINKER in two cases:
* if building for host Windows,
* if crosscompiling for target Windows.
It also skips adding '-fuse-ld=lld' to make lld-link not warning
about 'unknown argument'.
This fixes build with `clang/cmake/caches/DistributionExample.cmake`
on Windows.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80873
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
The `intrinsics_gen` target exists in the CMake exports since r309389
(see LLVMConfig.cmake.in), hence projects can depend on `intrinsics_gen`
even it they are built separately from LLVM.
Reviewed By: MaskRay, JDevlieghere
Differential Revision: https://reviews.llvm.org/D83454
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Summary:
`include/llvm/Frontend/OpenMP/CMakeLists.txt` creates a new target
called `omp_gen` which builds the generated include file `OMP.h.inc`.
This target must therefore be a dependency of every compilation step
whose transitive #include dependencies contain `OMP.h.inc`, or else
it's possible for builds to fail if Ninja (or make or whatever)
schedules that compilation step before building `OMP.h.inc` at all.
A few of those dependencies are currently missing, which leads to
intermittent build failures, depending on the order that Ninja (or
whatever) happens to schedule its commands. As far as I can see,
compiles in `clang/lib/CodeGen`, `clang/lib/Frontend`, and
`clang/examples` all depend transitivily on `OMP.h.inc` (usually via
`clang/AST/AST.h`), but don't have the formal dependency in the ninja
graph.
Adding `omp_gen` to the dependencies of `clang-tablegen-targets` seems
to be the way to get the missing dependency into the `clang/examples`
subdirectory. This also fixes the other two clang subdirectories, as
far as I can see.
Reviewers: clementval, thakis, chandlerc, jdoerfert
Reviewed By: clementval
Subscribers: cfe-commits, jdenny, mgorny, sstefan1, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D82659
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.
On Ubuntu, we want to raise default CLANG_SYSTEMZ_ARCH to z13,
thus allow configuring this via CMake.
On Debian, we want to raise it to z196.
Author: Dimitri John Ledkov
Differential Revision: https://reviews.llvm.org/D75914
In this case we interpret the path as relative the clang driver binary.
This allows SDKs to be built that include clang along with a custom
sysroot without requiring users to specify --sysroot to point to the
directory where they installed the SDK.
See https://github.com/WebAssembly/wasi-sdk/issues/58
Differential Revision: https://reviews.llvm.org/D76653
Make the install-llvm-libraries-stripped and install-clang-libraries-stripped
targets depend on the individual library stripped install targets, so
that they actually install the libraries.
Use a dedicated cmake file to store the extension configured within LLVM. That
way, a standalone build of clang can load this cmake file and get all the
configured standalone extensions.
This patch is related to https://reviews.llvm.org/D74602
Differential Revision: https://reviews.llvm.org/D74757
With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process.
This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus.
It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process.
Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means.
This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process.
At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before.
Differential Revision: https://reviews.llvm.org/D69825
I want to pass some CMake cache files in CLANG_BOOTSTRAP_CMAKE_ARGS as
`-C <cache file>.cmake` arguments. I want to be able to use the values
of the bootstrap passthrough variables in the cache files, so the cache
file arguments need to be after passthrough variables. This should be
safe because the values of passthrough variables are all constants and
can't refer to values in CLANG_BOOTSTRAP_CMAKE_ARGS.
Differential Revision: https://reviews.llvm.org/D71428
Add install targets as necessary to install bash-autocomplete,
scan-build and scan-view via LLVM_DISTRIBUTION_TARGETS.
Differential Revision: https://reviews.llvm.org/D68413
llvm-svn: 373695
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.
However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.
Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.
This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.
Differential revision: https://reviews.llvm.org/D64894
llvm-svn: 366447
"clang++ hello.cc --rtlib=compiler-rt"
now can works without specifying additional unwind or exception
handling libraries.
This reworked version of the feature no longer modifies today's default
unwind library for compiler-rt: which is nothing. Rather, a user
can specify -DCLANG_DEFAULT_UNWINDLIB=libunwind when configuring
the compiler.
This should address the issues from the previous version.
Update tests for new --unwindlib semantics.
Differential Revision: https://reviews.llvm.org/D59109
llvm-svn: 356508
Add an install target for clang's API headers, which allows them to be
included in distributions. The install rules already existed, but they
lacked a component and a target, making them only accessible via a full
install. These headers are useful for writing clang-based tooling, for
example. They're the clang equivalent to the llvm-headers target and
complement the clang-libraries target.
Differential Revision: https://reviews.llvm.org/D58317
llvm-svn: 355853
Summary: Not having this seems like an oversight, and makes stage2 builds odd.
Reviewers: ddunbar, dexonsmith
Subscribers: mgorny, jkorous, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59032
llvm-svn: 355547
r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE
instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more
directly and can be overridden by a user. Make the corresponding change
in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should
be available for both standalone and integrated builds.
Differential Revision: https://reviews.llvm.org/D58284
llvm-svn: 354525
Summary:
Handle the case where LLVM_MAIN_SRC_DIR is not set and also use
LLVM_CMAKE_DIR for locating installed cmake files rather than
LLVM_CMAKE_PATH.
Reviewers: phosek, andrewrk, smeenai
Reviewed By: phosek, andrewrk, smeenai
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D58204
llvm-svn: 354417
This is modeled after the existing llvm-libraries target. It's a
convenient way to include all clang libraries in a distribution.
This differs slightly from the llvm-libraries target in that it adds any
library added via add_clang_library, whereas llvm-libraries only
includes targets added via add_llvm_library that didn't use the MODULE
or BUILDTREE_ONLY arguments. add_clang_library doesn't appear to have
any equivalents of those arguments, so the conditions don't apply.
Differential Revision: https://reviews.llvm.org/D58269
llvm-svn: 354141
Summary: When building in an LLVM context, we should respect its LLVM_ENABLE_LIBXML2 option.
Reviewers: vitalybuka, mspertus, modocache
Reviewed By: modocache
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D53212
llvm-svn: 347870
After check-in of D54391 a comment there by @mikhail.ramalho says:
Since we're supporting version 4.8.1 now, the cmake file should be changed to
"minimum" instead of "exact".
Differential Revision: https://reviews.llvm.org/D54535
llvm-svn: 347152
When using multi-stage builds, we would like support cross-compilation.
Example is 2-stage build when the first stage is compiled for host while
the second stage is compiled for the target.
Normally, the second stage would be also used for compiling runtimes,
but that's not possible when cross-compiling, so we use the first stage
compiler instead. However, we still want to use the second stage paths.
To do so, we set the -resource-dir of the first stage compiler to point
to the resource directory of the second stage.
We also need compiler tools that support the target architecture. These
tools are not guaranteed to be present on the host, but in case of
multi-stage build, we can build these tools in the first stage.
Differential Revision: https://reviews.llvm.org/D54461
llvm-svn: 347025
Summary:
clang currently uses llvm-config to determine the installation paths
for llvm's headers and binaries. clang is also using LLVM's cmake
files to determine other information about the LLVM build, like
LLVM_LIBDIR_SUFFIX, LLVM_VERSION_*, etc. Since the installation
paths are also available via the cmake files, we can simplify the code
by only relying on information from cmake about the LLVM install and
dropping the use of llvm-config altogether.
In addition to simplifying the code, the cmake files have more
accurate information about the llvm installation paths. llvm-config
assumes that the lib, bin, and cmake directories are always located
in the same place relative to the path of the llvm-config executable.
This can be wrong if a user decides to install headers, binaries
or libraries to a non-standard location: e.g. static libraries
installed to /usr/lib/llvm6.0/
This patch takes the first step towards dropping llvm-config by
removing the automatic detection of llvm-config (users can still
manually supply a path to llvm-config by passing
-DLLVM_CONFIG=/usr/bin/llvm-config to cmake) and adding a
deprecation warning when users try to use this option.
Reviewers: chandlerc, beanz, mgorny, chapuni
Subscribers: mehdi_amini, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51714
llvm-svn: 346732
Make the check_include_file* macros honor CMAKE_REQUIRED_LIBRARIES. This
shouldn't cause any of the configuration checks to give different
results, and I verified that a clean configure before and after this
change resulted in identical CMake caches on my machine. The same change
was done for LLVM in r346377.
llvm-svn: 346378
Summary:
Enhanced support for Z3 in the cmake configuration of clang; now it is possible to specify any arbitrary Z3 install prefix (CLANG_ANALYZER_Z3_PREFIX) to cmake with lib (or bin) and include folders. Before the patch only in cmake default locations
were searched (https://cmake.org/cmake/help/v3.4/command/find_path.html).
Specifying any CLANG_ANALYZER_Z3_PREFIX will force also CLANG_ANALYZER_BUILD_Z3 to ON.
Removed also Z3 4.5 version requirement since it was not checked, and now Clang works with Z3 4.7
Reviewers: NoQ, george.karpenkov, mikhail.ramalho
Reviewed By: george.karpenkov
Subscribers: rnkovacs, NoQ, esteffin, george.karpenkov, delcypher, ddcc, mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50818
llvm-svn: 344464
Add a new CMake rule check-clang-python to run the Python bindings'
test suite, and include it in check-all.
Differential Revision: https://reviews.llvm.org/D52840
llvm-svn: 344258
Add a new CMake rule check-clang-python to run the Python bindings'
test suite, and include it in check-all.
Differential Revision: https://reviews.llvm.org/D52840
llvm-svn: 344241
Add installation support for the python bindings for libclang. Add an
additional CMake configuration variable to enumerate the python versions for
which the bindings should be installed. This allows for a LLVM/clang
distribution to distribute the python bindings for libclang as part of the
image. Because the python versions need to be explicitly stated by the user,
the default image remains unchanged.
llvm-svn: 340228
Since r334468, we no longer always copy the libcxx headers by virtue of
their presence when cmake runs.
This makes some of the later stages (compiler-rt, and the bootstrapped
stages) depend on them being copied, via the cxx-headers target.
Differential Revision: https://reviews.llvm.org/D48700
llvm-svn: 335898
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Thanks to Stella Stamenova for helping make this work on Windows.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335295
Header maps are binary files used by Xcode, which are used to map
header names or paths to other locations. Clang has support for
those since its inception, but there's not a lot of header map
testing around.
Since it's a binary format, testing becomes pretty much brittle
and its hard to even know what's inside if you don't have the
appropriate tools.
Add a python based tool that allows creating and dumping header
maps based on a json description of those. While here, rewrite
tests to use the tool and remove the binary files from the tree.
This tool was initially written by Daniel Dunbar.
Differential Revision: https://reviews.llvm.org/D46485
rdar://problem/39994722
llvm-svn: 335177
This allows adding additional bootstrap dependencies to the bootstrap
compiler that may be needed by later stages.
Differential Revision: https://reviews.llvm.org/D47355
llvm-svn: 334437
This CMake flag allows setting the default value for the
-f[no]-experimental-new-pass-manager flag.
Differential Revision: https://reviews.llvm.org/D44330
llvm-svn: 329366
Summary:
As we are only doing X.0.Z releases (not using the minor version), there is no need to keep -X.Y in the version.
So, instead, I propose the following:
Instead of having clang-7.0 in bin/, we will have clang-7
Since also matches was gcc is doing.
Reviewers: tstellar, dlj, dim, hans
Reviewed By: dim, hans
Subscribers: dim, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41808
llvm-svn: 328769
Provide two new CMake cache variables -- CLANG_DEFAULT_STD_C
and CLANG_DEFAULT_STD_CXX -- that can be used to override the default
C/ObjC and C++/ObjC++ standards appropriately. They can be set to one of
the identifiers from LangStandards.def, or left unset (the default) to
respect the current platform default.
This option is mostly intended for compiler vendors that may wish
to adjust the defaults their compilers are using. For example, Gentoo
planned to use it to set clang and gcc to matching standards, so that
we could maintain as much compatibility between different compilers
as possible.
The code relies on explicit identifiers rather than the string aliases
for simplicity. This saves us from the necessity of parsing aliases at
build-time or adding additional processing at runtime. For the latter
case, it also adds trivial value check -- if incorrect value is passed,
the code simply fails to compile through referencing an undefined
constant.
If the variable is used to redefine the default standard, the explicit
value overrides the special case for PS4. It is done this way mostly
following other kinds of variables where 'platform defaults' are
redefined.
Differential Revision: https://reviews.llvm.org/D34365
llvm-svn: 326836
Summary:
When setting CMAKE_ASM_COMPILER=clang, we also need to set
CMAKE_ASM_COMPILER_ID=Clang.
This is needed because cmake won't set CMAKE_ASM_COMPILER_ID if
CMAKE_ASM_COMPILER is already set.
Without CMAKE_ASM_COMPILER_ID, cmake can't set
CMAKE_ASM_COMPILER_OPTIONS_TARGET either, which means
CMAKE_ASM_COMPILER_TARGET is ignored, causing cross compiling to fail,
i.e., `--target=${CMAKE_ASM_COMPILER_TARGET}` isn't passed.
Differential Revision: https://reviews.llvm.org/D42232
llvm-svn: 322977
The current implementation of the nvptx runtime (to be upstreamed shortly) uses the atomicMax operation on 64-bit integers.
This is only supported in compute capabilities 3.5 and later. I've changed the clang default to sm_35.
Differential Revision: https://reviews.llvm.org/D40977
llvm-svn: 320082
Using comma can break in cases when we're passing flags that already
use comma as a separator.
Fixes PR35504.
Differential Revision: https://reviews.llvm.org/D40762
llvm-svn: 319720
Passthrough LLVM_ENABLE_{PROJECTS,RUNTIMES} to followup stages to
support the side-by-side checkouts (aka monorepo layout).
Differential Revision: https://reviews.llvm.org/D40258
llvm-svn: 319267
Escaping ; in list arguments passed to ExternalProject_Add doesn't seem
to be working in newer versions of CMake (see
https://public.kitware.com/Bug/view.php?id=16137 for more details). Use
a custom LIST_SEPARATOR instead which is the officially supported way.
Differential Revision: https://reviews.llvm.org/D40257
llvm-svn: 319264
After the recent lit test changes, clang attempts to run its tests
via llvm-lit by default. However, the llvm-lit binary is not present
when performing stand-alone build resulting in a failure out of the box.
To solve that, add the llvm-lit directory to CMake when performing
a stand-alone build and LLVM sources are provided. This includes
the CMake rules generating the llvm-lit binary and effectively makes
it possible for clang to use it.
Differential Revision: https://reviews.llvm.org/D40142
llvm-svn: 318562
llvm-objcopy is getting to where it can be used in non-trivial ways
(such as for dwarf fission in clang). It now supports dwarf fission but
this feature hasn't been thoroughly tested yet. This change allows
people to optionally build clang to use llvm-objcopy rather than GNU
objcopy. By default GNU objcopy is still used so nothing should change.
Differential Revision: https://reviews.llvm.org/D39029
llvm-svn: 317960
For the shuffle instructions in reductions we need at least sm_30
but the user may want to customize the default architecture.
Differential Revision: https://reviews.llvm.org/D38883
llvm-svn: 315996
Summary:
The clang-proto-fuzzer models a subset of C++ as a protobuf and
uses libprotobuf-mutator to generate interesting mutations of C++
programs. Clang-proto-fuzzer has already found several bugs in
Clang (e.g., https://bugs.llvm.org/show_bug.cgi?id=33747,
https://bugs.llvm.org/show_bug.cgi?id=33749).
As with clang-fuzzer, clang-proto-fuzzer requires the following
cmake flags:
- CMAKE_C_COMPILER=clang
- CMAKE_CXX_COMPILER=clang++
- LLVM_USE_SANITIZE_COVERAGE=YES // needed for libFuzzer
- LLVM_USE_SANITIZER=Address // needed for libFuzzer
In addition, clang-proto-fuzzer requires:
- CLANG_ENABLE_PROTO_FUZZER=ON
clang-proto-fuzzer also requires the following dependencies:
- binutils // needed for libprotobuf-mutator
- liblzma-dev // needed for libprotobuf-mutator
- libz-dev // needed for libprotobuf-mutator
- docbook2x // needed for libprotobuf-mutator
- Recent version of protobuf [3.3.0 is known to work]
A working version of libprotobuf-mutator will automatically be
downloaded and built as an external project.
Implementation of clang-proto-fuzzer provided by Kostya
Serebryany.
https://bugs.llvm.org/show_bug.cgi?id=33829
Reviewers: kcc, vitalybuka, bogner
Reviewed By: kcc, vitalybuka
Subscribers: thakis, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D36324
llvm-svn: 310408
By creating this target other projects that depend on clang-generated headers (like LLDB) will no longer be order-dependent on Clang being processed by CMake first.
Also, by creating a dummy of this target in ClangConfig.cmake, projects that can build against out-of-tree clang can freely depend on the target without needing to have conditionals for if clang is in-tree or out-of-tree.
llvm-svn: 309390
This gets rid of almost LLVM targets unconditionally depending on intrinsic_gen.
Clang's modules still have weird dependencies and hard to remove intrinsics_gen in better way.
Then, it'd be better to give whole clang targets depend on intrinsic_gen.
llvm-svn: 308844
LLVM_ENABLE_MODULES is sensitive of -D. Move them into config.h.
FIXME: It'd be better that they are #cmakedefine01 rather than #cmakedefine.
(#if FOO rather than #if defined(FOO))
Then we can find missing #include "clang/Config/config.h" in the future.
Differential Revision: https://reviews.llvm.org/D35527
llvm-svn: 308277
Summary:
This is a first patch for GSoC project, bash-completion for clang.
To use this on bash, please run `source clang/utils/bash-autocomplete.sh`.
bash-autocomplete.sh is code for bash-completion.
Simple flag completion and path completion is available in this patch.
Reviewers: teemperor, v.g.vassilev, ruiu, Bigcheese, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33237
llvm-svn: 303670
CMake handles paths with slashes. It caused cmake/install failure on msbuild.exe.
Note, Other llvm-config-oriented variables have been normalized since they are stored in the cache attributed with PATH.
llvm-svn: 294954
Use the new llvm_canonicalize_cmake_booleans() function to canonicalize
booleans for lit tests. Replace the duplicate ENABLE_CLANG* variables
used to hold canonicalized values with in-place canonicalization. Use
implicit logic in Python code to avoid overrelying on exact 0/1 values.
Differential Revision: https://reviews.llvm.org/D28529
llvm-svn: 293052
These two are independent: it's possible to use LLD without LTO,
and it's possible to do LTO build without LLD.
Differential Revision: https://reviews.llvm.org/D28821
llvm-svn: 292343
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.
Differential Revision: https://reviews.llvm.org/D26900
llvm-svn: 291495
This diff fixes the clean build of the target generate-order-file.
In llvm/tools/clang/CMakeLists.txt
add_subdirectory(utils/perf-training) should go after the block where
the value of the variable CLANG_ORDER_FILE is set - otherwise
(tested with cmake's version 3.6.2) the arguments of perf-helper.py gen-order-file
will be ill-formed (CLANG_ORDER_FILE will be empty).
Differential revision: https://reviews.llvm.org/D28153
llvm-svn: 290781
This change allows setting the default linker used by the Clang
driver when configuring the build.
Differential Revision: https://reviews.llvm.org/D25263
llvm-svn: 289668
lld has LTO support, if requested we should add a dependency on lld
rather than LLVMgold when doing LTO bootstrap build.
Differential Revision: https://reviews.llvm.org/D26649
llvm-svn: 287179
Having this target allows other parts of the build system to add to the bootstrap dependencies without needing to be defined before the bootstrap targets are created.
This will specifically be used connect the builtins build from the LLVM runtimes directory as a dependency of the next build stage.
llvm-svn: 284648
Update the lit search logic to support all names supported in LLVM
(since r283029). The search order (i.e. PATHS vs HINTS) does no really
matter since the established path is not used, except for determining
whether lit is available.
Differential Revision: https://reviews.llvm.org/D23745
llvm-svn: 284496
Checking if they evaluate to true cases prevents passing values that evaluate to false cases. Instead we should check if the variables are defined.
llvm-svn: 282122
Currently, the Clang version is computed as follows:
1. LLVM defines major, minor, and patch versions, all statically set. Today,
these are 4, 0, and 0, respectively.
2. The static version numbers are combined into PACKAGE_VERSION along with a
suffix, so the result today looks like "4.0.0svn".
3. Clang extracts CLANG_VERSION from PACKAGE_VERSION using a regexp. The regexp
allows the patch level to omitted, and drops any non-digit trailing values.
Today, this result looks like "4.0.0".
4. CLANG_VERSION is then split further into CLANG_VERSION_MAJOR and
CLANG_VERSION_MINOR. Today, these resolve to 4 and 0, respectively.
5. If CLANG_VERSION matches a regexp with three version components, then
CLANG_VERSION_PATCHLEVEL is extracted and the CLANG_HAS_VERSION_PATCHLEVEL
variable is set to 1. Today, these values are 0 and 1, respectively.
6. The CLANG_VERSION_* variables (and CLANG_HAS_VERSION_PATCHLEVEL) are
configured into [llvm/tools/clang/]include/clang/Basic/Version.inc
verbatim by CMake.
7. In [llvm/tools/clang/]include/clang/Basic/Version.h, macros are defined
conditionally, based on CLANG_HAS_VERSION_PATCHLEVEL, to compute
CLANG_VERSION_STRING as either a two- or three-level version number. Today,
this value is "4.0.0", because despite the patchlevel being 0, it was
matched by regexp and is thus "HAS"ed by the preprocessor. This string is
then used wherever Clang's "version" is needed [*].
[*] Including, notably, by compiler-rt, for computing its installation path.
This change collapses steps 2-5 by defaulting Clang to use LLVM's (non-string)
version components for the Clang version (see [*] for why not PACKAGE_VERSION),
and collapses steps 6 and 7 by simply writing CLANG_VERSION_STRING into
Version.inc. The Clang version today always uses the patchlevel form, so the
collapsed Version.inc does not have logic for a version without a patch level.
Historically speaking, this technique began with the VER file in r82085 (which
survives in the form of the regexp in #3). The major, minor, and patchlevel
versions were introduced by r106863 (which remains in #4-6). The VER file itself
was deleted in favor of the LLVM version number in r106914. On the LLVM side,
the individual LLVM_VERSION_MAJOR, LLVM_VERSION_MINOR, and PACKAGE_VERSION
weren't introduced for nearly two more years, until r150405.
llvm-svn: 281666
Summary:
Add a cmake check for sys/resource.h and replace the __has_include() check with its result, in order to make it possible to use rlimits when building with compilers not supporting __has_include() -- i.e. when bootstrapping.
// Please also re-apply dfcd52eb1d8e5d322404b40414cb7331c7380a8c (llvm-config.h fix)
Patch by: Michał Górny
Reviewers: rsmith, beanz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23744
llvm-svn: 279559
This patch adds a few new convenience options used by the PGO CMake cache to setup options on bootstrap stages. The new options are:
PGO_INSTRUMENT_LTO - Builds the instrumented and final builds with LTO
PGO_BUILD_CONFIGURATION - Accepts a CMake cache script that can be used for complex configuration of the stage2-instrumented and stage2 builds.
The patch also includes a fix for bootstrap dependencies so that the instrumented LTO tools don't get used when building the final stage, and it adds distribution targets to the passthrough.
llvm-svn: 278862
This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru
which we can specify a default value for -rtlib (libgcc or
compiler-rt) at build time, just like how we set the default C++
stdlib thru CLANG_DEFAULT_CXX_STDLIB.
With these two options, we can configure clang to build binaries on
Linux that have no runtime dependence on any gcc libs (libstdc++ or
libgcc_s).
Patch by Lei Zhang!
Differential Revision: https://reviews.llvm.org/D22663
llvm-svn: 276848
Kristina Bessonova