Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.
A previous patch broke that workflow, so this is making it work
again. Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces. libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.
Differential Revision: https://reviews.llvm.org/D38057
llvm-svn: 313763
The motivation is to be able to check sources outside the current
directory. See D31363 for example usage.
Differential Revision: https://reviews.llvm.org/D37859
llvm-svn: 313648
After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.
llvm-svn: 313643
This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.
There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree. Since there's
no LLVM source tree, there's no LLVM CMake. CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.
llvm-svn: 313607
It looks like this is going to be non-trivial to get working
in both Py2 and Py3, so for now I'm reverting until I have time
to fully test it under Python 3.
llvm-svn: 313429
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functionality such as setting up paths, adding features that are
useful across all projects, and other utility-type functions.
For now this only updates llvm's suite to use this new library,
but subsequent patches will update other projects.
Differential Revision: https://reviews.llvm.org/D37778
llvm-svn: 313325
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
This was intended to be a generic CMake solution to a problem
shared across several projects. It turns out it doesn't interact
very well certain CMake configurations, and furthermore the
"problem" is actually not a problem, as the problematic code
is never executed to begin with. So this really isn't solving
anything.
llvm-svn: 313191
Some projects need to add conditional dependencies on other projects.
compiler-rt is already doing this, and I attempted to add this to
debuginfo-tests when I ran into the ordering problem, that you can't
conditionally add a dependency unless that dependency's CMakeLists.txt
has already been run (which would allow you to say if (TARGET foo).
The solution to this seems to be to determine very early on the entire
set of projects which is enabled. This is complicated by the fact that
there are multiple ways to enable projects, and different tree layouts
(e.g. mono-repo, out of -tree, external, etc). This patch attempts to
centralize all of this into one place, and then updates compiler-rt to
demonstrate as a proof of concept how this can simplify code.
Differential Revision: https://reviews.llvm.org/D37637
llvm-svn: 313091
Summary:
When repo is used with git, 'clang --version' option does not display
the correct revision information (i.e. git hash on TOP) as the following:
clang version 6.0.0 --->
clang version 6.0.0 (clang version) (llvm version)
This is because repo also creates .git/svn folder as git-svn does and
this makes repo with git uses "git svn info" command, which is only for
git-svn, to retrieve its revision information, making null for the info.
To correctly distinguish between git-svn and repo with git, the folder
hierarchy to specify for git-svn should be .git/svn/refs as the "git svn
info" command depends on the revision data in .git/svn/refs. This patch
in turn makes repo with git passes through to the third macro,
get_source_info_git, in get_source_info function, resulting in correctly
retrieving the revision information for repo with git using "git log ..."
command.
This patch is tested with git, svn, git-svn, and repo with git.
Reviewers: llvm-commits, probinson, rnk
Reviewed By: rnk
Subscribers: rnk, mehdi_amini, beanz, mgorny
Differential Revision: https://reviews.llvm.org/D35532
llvm-svn: 312864
FuzzMutate might not be the best place for these, but it makes more
sense than an entirely new library for now. This will make setting up
fuzz targets with consistent CLI handling easier.
llvm-svn: 312425
Summary:
Move version control macros, find_first_existing_file and
find_first_existing_vc_file to AddLLVM.cmake so they can be reused by sub projects
like clang.
Differential Revision: https://reviews.llvm.org/D36971
llvm-svn: 312419
This is needed for building LLVM on Android with new NDK (newer
than r15c) and API level < 24. Android C library (Bionic) didn't have
support for 64 bit file position until Android N.
Differential Revision: https://reviews.llvm.org/D37314
llvm-svn: 312389
This adds a dummy main so we can build and run the llvm-isel-fuzzer
functionality when we aren't building LLVM with coverage. The approach
here should serve as a template to stop in-tree fuzzers from
bitrotting (See llvm.org/pr34314).
Note that I'll probably move most of the logic in DummyISelFuzzer's
`main` to a library so it's easy to reuse it in other fuzz targets,
but I'm planning on doing that in a follow up that also consolidates
argument handling in our LLVMFuzzerInitialize implementations.
llvm-svn: 312338
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
llvm-svn: 312246
Clang 5 supports -Wstrict-prototypes. We should use it to catch any C
declarations that declare a non-prototype function.
rdar://33705313
Differential Revision: https://reviews.llvm.org/D36669
llvm-svn: 312240
This moves the cmake configuration for fuzzers in LLVM to a new macro,
add_llvm_fuzzer. This will make it easier to keep things consistent
while implementing llvm.org/pr34314.
I've also made a couple of minor functional changes here:
- the fuzzers now use add_llvm_executable rather than add_llvm_tool.
This means they won't create install targets and stuff like that,
because those made little sense for these fuzzers.
- I've grouped these under "Fuzzers" rather than in with "Tools" for
people who build with IDEs.
llvm-svn: 312200
Summary:
Plugins can (and should) be enabled under mingw if we are building
libLLVM.dll, so this is just a missed case. This allows LLVMgold.dll to
be built now under mingw.
Reviewers: llvm-commits, pirama, beanz, chapuni
Reviewed By: chapuni
Subscribers: chapuni, mgorny
Differential Revision: https://reviews.llvm.org/D37116
llvm-svn: 311973
This fixes an issue with the use of LLVM_PARALLEL_LINK_JOBS.
Original commit message:
macOS 10.13 added a new API (futimens). This API is only available on macOS 10.13
and later, but the cmake check we have in place only tests if the symbol is
present and ignores the availability attribute. Luckily we have new warning for
this and by making this warning an error the cmake check will return the correct
result.
See also rdar://problem/33992750.
Differential Revision: https://reviews.llvm.org/D37027
llvm-svn: 311965
macOS 10.13 added a new API (futimens). This API is only available on macOS 10.13
and later, but the cmake check we have in place only tests if the symbol is
present and ignores the availability attribute. Luckily we have new warning for
this and by making this warning an error the cmake check will return the correct
result.
See also rdar://problem/33992750.
Differential Revision: https://reviews.llvm.org/D37027
llvm-svn: 311949
Summary:
The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LLVMARMInfo, LLVMAArch4Info, etc appearing twice in `extract_symbols.py` command line while building `clangShared`. `Extract_symbols.py` does not work well in such a case and completely ignores the symbols from the duplicated libraries. Thus, the LLVM(...)Info symbols do not get exported from `clangShared` and linking clang against it fails with unresolved dependencies.
Seems to be a mere copy-paste mistake.
Reviewers: beanz, chapuni
Reviewed By: chapuni
Subscribers: chapuni, aemerson, mgorny, kristof.beyls, llvm-commits, asl
Differential Revision: https://reviews.llvm.org/D36119
llvm-svn: 310590
Detect [/-][DU]NDEBUG in CMAKE_C_FLAGS* and pass them through to ocamlc.
This is necessary because their value might affect visibility of dump
functions in LLVM and ocamlc uses its own compiler and flags by default.
Differential Revision: https://reviews.llvm.org/D35898
llvm-svn: 309483
Install the OCaml dynamic libraries in the 'stubdirs' directory rather
than the llvm subdirectory in order to fix running executables created
by ocamlc. Otherwise, the executables fail to run being unable to locate
the libraries (unless the LLVM directory is explicitly added to
LD_LIBRARY_PATH).
The staging directories are not altered since they work for our
development setup anyway, and installing into two directories would
unnecessarily make the code more complex.
Differential Revision: https://reviews.llvm.org/D35995
llvm-svn: 309481
By creating a dummy of this target in LLVMConfig.cmake, projects that can build against out-of-tree LLVM can freely depend on the target without needing to have conditionals for if LLVM is in-tree or out-of-tree.
llvm-svn: 309389
Pass the values of CMAKE_C_FLAGS and CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE}
as -ccopt to ocamlc. This enforces the specific flags used for the LLVM
build to be used for OCaml bindings as well, notably -O and -march
flags.
This also solves the issue of the user being unable to force specific
flags for OCaml bindings builds. Gentoo needs this to enforce -DNDEBUG
consistently between the LLVM build and the split OCaml bindings build.
Differential Revision: https://reviews.llvm.org/D35898
llvm-svn: 309320
-Werror may cause some of the CMake checks to fail, so we disable
it even if it's enabled for the build itself.
Differential Revision: https://reviews.llvm.org/D35924
llvm-svn: 309235
compile_commands.json file is very useful both for tooling and for
reproducible builds.
For files generated from recursive CMake invocation this information was
not previously generated.
Differential Review: https://reviews.llvm.org/D35219
llvm-svn: 308698
Summary:
GetSVN.cmake currently takes one or two pairs of <source directory path,
name>, then attempts to get the remote repository URL and source control
revision of the repositories at those one or two paths.
It takes two pairs in order for Clang to get the revision of both
itself, and its dependency LLVM.
For projects that rely upon both LLVM and Clang (Apple's Swift is one
example, but there are others), GetSVN.cmake is used to fetch *three*
revisions: Swift, Clang, and LLVM.
To support this use case, change GetSVN.cmake: instead of taking one or
two pairs (specified via `FIRST_SOURCE_DIR`/`FIRST_NAME`, have it take a list
of pairs (`SOURCE_DIRS`/`NAMES`).
In order to allow Clang to migrate, have GetSVN.cmake support both sets
of arguments for now. The old arguments can be removed once Clang begins
using the new arguments, and Swift can follow when it updates its
copy of LLVM.
Test Plan:
1. Perform a clean build of Clang, verify that `clang --version` still
prints the correct LLVM and Clang revision information.
2. Modify Clang's CMake to use the new arguments, then perform another
clean build. `clang --version` should still print the correct
revision information.
Reviewers: jordan_rose, beanz, probinson
Subscribers: echristo, chapuni, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35132
llvm-svn: 308507
Solaris ld is not the only linker available on Solaris.
Introducing linker detection and using LLVM_LINKER_IS_SOLARISLD to
select Solaris-ld specific handling.
Patch by: Fedor Sergeev
Differential Revision: https://reviews.llvm.org/D35325
llvm-svn: 307852
Solaris ld interprets -color-diagnostics as a -c option, so it is
better to use --color-diagnostics instead. lld accepts both.
Differential Revision: https://reviews.llvm.org/D35327
llvm-svn: 307850
This changes adds support for building runtimes for multiple
different targets using LLVM runtimes directory.
The implementation follow the model used already by the builtins
build which already supports this option. To specify the runtimes
targets to be built, use the LLVM_RUNTIME_TARGETS variable, where
the valuae is the list of targets to build runtimes for. To pass
a per target variable to the runtimes build, you can set
RUNTIMES_<target>_<variable> where <variable> will be passed to the
runtimes build for <target>.
Each runtime target (except for the default one) will be installed
into lib/<target> subdirectory. Build targets will be suffixed with
the target name.
Differential Revision: https://reviews.llvm.org/D32816
llvm-svn: 307731
Summary:
This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils
that are installed when the LLVM_INSTALL_UTILS. This option
defaults to 'bin' to remain consistent with the current behavior, but
distros may want to install these to libexec/llvm.
Reviewers: beanz
Reviewed By: beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30655
llvm-svn: 307150
CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja).
So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is.
Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory.
Differential Revision: https://reviews.llvm.org/D33707
llvm-svn: 305961
This commit causes LLVM_USE_SANITIZER to now accept the "Leaks" option. This
will cause cmake to pass in -fsanitize=leak in all of the appropriate places.
I am making this change so that I can setup a linux bot that only detects
leaks.
llvm-svn: 305839
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
llvm-svn: 305632
LLVM_TABLEGEN_TARGET is undefined in clang standalone build.
STREQUAL cannot omit LHS. Then I saw an error;
CMake Error at /path/to/install/llvm/lib/cmake/llvm/TableGen.cmake:40 (if):
if given arguments:
"STREQUAL" "/path/to/install/llvm/bin/llvm-tblgen.exe"
Unknown arguments specified
llvm-svn: 305159
For the case when LLVM_OPTIMIZED_TABLEGEN is ON (enables LLVM_USE_HOST_TOOLS),
we need both _TABLEGEN_TARGET and _TABLEGEN_EXE in the DEPENDS list
to have .inc files rebuilt on a tablegen change, as cmake does not propagate
file-level dependencies of custom targets.
We could always have just one dependency on both the target and
the file, but the 2 cases would produce cleaner cmake files.
llvm-svn: 305142
Summary:
Reverse iteration can be turned on, by default, by setting -DLLVM_REVERSE_ITERATION:BOOL=ON during cmake.
With this enabled, we can uncover lots of cases of non-determinism in codegen by simply running our tests (without any other change).
We can then setup a buildbot which will have this turned on by default. Initially, a lot of unit tests will fail in this configuration.
Once we start fixing non-determinism issues, we can gradually make this a blocker for patches.
Reviewers: davide, dblaikie, mehdi_amini, dberlin
Reviewed By: dblaikie
Subscribers: probinson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33908
llvm-svn: 304757
Summary:
This was broken by r302499. Configuring with -DLLVM_BUILD_DOCS=ON would
cause the docs-llvm-man target not to be created.
Reviewers: anemet, beanz
Reviewed By: anemet
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33146
llvm-svn: 303042
Summary:
When using ThinLTO, the linker performs its own parallelism. This
change limits the number of parallel link jobs that Ninja will issue
to keep the total number of threads reasonable when linking with
ThinLTO.
Reviewers: hans, ruiu
Subscribers: mgorny, mehdi_amini, Prazek
Differential Revision: https://reviews.llvm.org/D31990
llvm-svn: 301676
Summary:
This patch adds a very simple linker script to version the lib's symbols
and thus trying to avoid crashes if an application loads two different
LLVM versions (as long as they do not share data between them).
Note that we deliberately *don't* make LLVM_5.0 depend on LLVM_4.0:
they're incompatible and the whole point of this patch is
to tell the linker that.
Avoid unexpected crashes when two LLVM versions are used in the same process.
Author: Rebecca N. Palmer <rebecca_palmer@zoho.com>
Author: Lisandro Damían Nicanor Pérez Meyer <lisandro@debian.org>
Author: Sylvestre Ledru <sylvestre@debian.org>
Bug-Debian: https://bugs.debian.org/848368
Reviewers: beanz, rnk
Reviewed By: rnk
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D31524
llvm-svn: 300496
This is a magic header file supported by the build system that provides a
single definition, LLVM_REVISION, containing an LLVM revision identifier,
if available. This functionality previously lived in the LTO library, but
I am moving it out to lib/Support because I want to also start using it in
lib/Object to create the IR symbol table.
This change also fixes a bug where LLVM_REVISION was never actually being
used in lib/LTO because the macro HAS_LLVM_REVISION was never defined (it
was misspelled as HAVE_SVN_VERSION_INC in lib/LTO/CMakeLists.txt, and was
only being defined in a non-existent file Version.cpp).
I also changed the code to use "git rev-parse --git-dir" to locate the .git
directory, instead of looking for it in the LLVM source root directory,
which makes this compatible with monorepos as well as git worktrees.
Differential Revision: https://reviews.llvm.org/D31985
llvm-svn: 300160
CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided
for host compiler that builds llvm components. A function
add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep
track of these definitions and was intended to be a replacement for CMake
command add_definitions. Actually in many cases add_definitions is still
used and the content of LLVM_DEFINITIONS is not actual now. On the other
hand the current version of CMake allows getting set of definitions in a
more convenient way. This fix implements evaluation of the variable by
reading corresponding cmake property.
Differential Revision: https://reviews.llvm.org/D31125
llvm-svn: 298336
Summary:
clang-cl understands the GCC-style -W[no-]foo flags, and for the most
part ignores MSVC -wd flags. So, let's pass the curated set of warning
flags we use on Unix on Windows. We can also stop passing /W4 -wd*,
which for the most part corresponds to -Wall -Wextra with a bunch of
flags that we mostly ignore.
I had to disable -Wnon-virtual-dtor on Windows, because it fires on
every COM class ever. I filed PR32286 to fix this.
So far I've only found two instances of -Wstring-conversion in the
WinASan code, which I'll fix. Other than that we seem clean.
Reviewers: hans
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30992
llvm-svn: 297964
When CMAKE_INSTALL_MANDIR isn't defined it ends up attempting to install
the man pages under "/man1" and we really don't want to accidentally install
stuff at the filesystem root.
llvm-svn: 297545
Summary:
The add_tablegen macros defines its own install target, and it was also calling
add_llvm_utility which adds another install target.
Configuring with -DLLVM_TOOLS_INSTALL_DIR set to something other than
'bin' along with -DLLVM_INSTALL_UTILS=ON was causing llvm-tablgen
to be installed to two separate directories.
Reviewers: beanz, hans
Reviewed By: beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30656
llvm-svn: 297403
X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible.
It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals.
This TableGen backend replaces the tables by automatically generating them.
Differential Revision: https://reviews.llvm.org/D30451
llvm-svn: 297127
Summary:
Fix a few problems in VersionFromVCS.cmake to make it more reliable:
- Stop using git svn info to retrieve the svn revision. I am unable to
determine what the svn revision returned by this command means.
During my testing this command returned a revision from a month
ago which was not the HEAD of any of my local branches.
Also, this revision was never actually added to the version string due
to a typo in the script. All it was used for was to reject the
revision number returned by git svn find-rev HEAD when the revision
numbers didn't match.
- Populate GIT_COMMIT even when we detect a git repo without any
svn information.
Reviewers: mehdi_amini, beanz
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D30092
llvm-svn: 296829
Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused.
Reviewers: rnk, ruiu, hans
Reviewed By: hans
Subscribers: mgorny, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30240
llvm-svn: 296658
To help assist in debugging ISEL or to prioritize GlobalISel backend
work, this patch adds two more tables to <Target>GenISelDAGISel.inc -
one which contains the patterns that are used during selection and the
other containing include source location of the patterns
Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV
llvm-svn: 295081
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies.
Reviewers: mgorny, chapuni, bryant
Subscribers: llvm-commits, jgosnell
Differential Revision: https://reviews.llvm.org/D28869
llvm-svn: 294514
Summary:
r291918 changed `HandleLLVMOptions.cmake` to add `-fsanitize-blacklist=<llvm-file>` when `LLVM_USE_SANITIZER=Undefined` is specified. This breaks out-of-tree users of `LLVM_USE_SANITIZER` since that file is not present.
This patch fixes the issue by checking if the file exists first.
Reviewers: mgorny, bogner, vitalybuka, krasin
Reviewed By: krasin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29686
llvm-svn: 294367
Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them.
llvm-svn: 294334
Summary: This adds a fallback in case that the Intel compiler is failed to be detected correctly.
Reviewers: chapuni
Reviewed By: chapuni
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27610
llvm-svn: 293230
In r292256, we started adding -fsanitize-use-after-scope when using
the address sanitizer, but that flag wasn't always available. This
fixes the config to only add the flag if the host compiler supports
it.
llvm-svn: 292423
Update SOVERSION to use just the major version number rather than
major+minor, to match the new versioning scheme where only major is used
to indicate API/ABI version.
Since two-digit SOVERSIONs were introduced post 3.9 branching, this
change does not risk any SOVERSION collisions. In the past,
two-component X.Y SOVERSIONs were shortly used but those will not
interfere with the new ones since the new versions start at 4.
Differential Revision: https://reviews.llvm.org/D28730
llvm-svn: 292255
Summary:
This string parameter is passed to -fuse-ld when linking. It can be
an absolute path to your custom linker, otherwise clang will look for
`ld.{name}`.
Reviewers: davide, tejohnson, pcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28738
llvm-svn: 292047
Summary:
libstdc++ has some undefined behavior in bits/stl_tree.h that
has recently became excercised by some of the LLVM code.
Given that fixing libstdc++ will take years, adding the file
into a blacklist to fix bots seems like a necessity.
Reviewers: vitalybuka
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28686
llvm-svn: 291918
I have two immediate motivations for adding this:
1) It makes writing expectations in tests *dramatically* easier. A
quick example that is a taste of what is possible:
std::vector<int> v = ...;
EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3));
This checks that v contains '1', '2', and '3' in some order. There
are a wealth of other helpful matchers like this. They tend to be
highly generic and STL-friendly so they will in almost all cases work
out of the box even on custom LLVM data structures.
I actually find the matcher syntax substantially easier to read even
for simple assertions:
EXPECT_THAT(a, Eq(b));
EXPECT_THAT(b, Ne(c));
Both of these make it clear what is being *tested* and what is being
*expected*. With `EXPECT_EQ` this is implicit (the LHS is expected,
the RHS is tested) and often confusing. With `EXPECT_NE` it is just
not clear. Even the failure error messages are superior with the
matcher based expectations.
2) When testing any kind of generic code, you are continually defining
dummy types with interfaces and then trying to check that the
interfaces are manipulated in a particular way. This is actually what
mocks are *good* for -- testing *interface interactions*. With
generic code, there is often no "fake" or other object that can be
used.
For a concrete example of where this is currently causing significant
pain, look at the pass manager unittests which are riddled with
counters incremented when methods are called. All of these could be
replaced with mocks. The result would be more effective at testing
the code by having tighter constraints. It would be substantially
more readable and maintainable when updating the code. And the error
messages on failure would have substantially more information as
mocks automatically record stack traces and other information *when
the API is misused* instead of trying to diagnose it after the fact.
I expect that #1 will be the overwhelming majority of the uses of gmock,
but I think that is sufficient to justify having it. I would actually
like to update the coding standards to encourage the use of matchers
rather than any other form of `EXPECT_...` macros as they are IMO
a strict superset in terms of functionality and readability.
I think that #2 is relatively rarely useful, but there *are* cases where
it is useful. Historically, I think misuse of actual mocking as
described in #2 has led to resistance towards this framework. I am
actually sympathetic to this -- mocking can easily be overused. However
I think this is not a significant concern in LLVM. First and foremost,
LLVM has very careful and rare exposure of abstract interfaces or
dependency injection, which are the most prone to abuse with mocks. So
there are few opportunities to abuse them. Second, a large fraction of
LLVM's unittests are testing *generic code* where mocks actually make
tremendous sense. And gmock is well suited to building interfaces that
exercise generic libraries. Finally, I still think we should be willing
to have testing utilities in tree even if they should be used rarely. We
can use code review to help guide the usage here.
For a longer and more complete discussion of this, see the llvm-dev
thread here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html
The general consensus seems that this is a reasonable direction to start
down, but that doesn't mean we should race ahead and use this
everywhere. I have one test that is blocked on this to land and that was
specifically used as an example. Before widespread adoption, I'm going
to work up some (brief) guidelines as some of these facilities should be
used sparingly and carefully.
Differential Revision: https://reviews.llvm.org/D28156
llvm-svn: 291606
Some GCC versions will accept any warning flag name after a '-Wno-',
which would cause us to try to disable warnings with names GCC didn't
understand. This will silently succeed unless there is some other output
from GCC in which case we get weird cc1plus warnings about the warning
name being bogus.
There is still the issue that gtest sets warning flags for building
gtest-all.cc using weird 'add_definitions' and the fact that there is
a GCC version which warns on the variadic macro usage in gtest under
-pedantic, but has no flag analogous to Clang's
-Wgnu-zero-variadic-macro-argumnets to suppress this warning. I haven't
been able to come up with any good solution here. The closest is to turn
off -pedantic for those versions of GCC, but that seems really nasty.
For now, those versinos of GCC aren't warning clean. If anyone is broken
by this, I'll work on CMake logic to detect and disable -pedantic in
these cases.
llvm-svn: 291299
Canonicalize all CMake booleans to 0/1 before passing them to lit, to
ensure that the Python side handles all of them consistently
and correctly. 0/1 is a safe choice of values that trigger the same
boolean interpretation in CMake, Python and C++.
Furthermore, using them without quotes improves the chance Python will
explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE,
YES/NO) is accidentally passed, rather than silently misinterpreting
the value.
This replaces a lot of different logics spread around lit site files,
attempting to partially reproduce the boolean logic used in CMake
and usually silently failing when an uncommon value was used instead.
In fact, some of them were never working correctly since different
values were assigned in CMake and checked in Python.
The alternative solution could be to create a common parser for CMake
booleans in lit and use it consistently throughout the site files.
However, it does not seem like the best idea to create redundant
implementation of the same logic and have to follow upstream if it ever
is extended to handle more values.
Differential Revision: https://reviews.llvm.org/D28294
llvm-svn: 291284
I somehow wrote this fix and then lost it prior to commit. Really sorry
about the noise. This should fix some issues with hacking add_definition
to do things with warning flags.
llvm-svn: 291033
I'm not sure what determines the minor version, but it appears
that it's possible for a fully updated, release version of
VS2015 with Update 3 can go (at least) as low as 19.00.24213.1.
Updating the compiler version check to account for this so we
don't generate superfluous warnings.
llvm-svn: 290914
Add an explicit LLVM_ENABLE_DIA_SDK option to control building support
for DIA SDK-based debugging. Control its value to match whether DIA SDK
support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB).
Its value is needed for LLDB to determine whether to run tests requiring
DIA support. Currently it is obtained from llvm/Config/config.h;
however, this file is not available for standalone builds. Following
this change, LLDB will be modified to use the value from LLVMConfig.
Differential Revision: https://reviews.llvm.org/D26255
llvm-svn: 290818
COFF has a 2**16 section limit, and on Win64, every COMDAT function
creates at least 3 sections: .text, .pdata, and .xdata. For MSVC, we
enable bigobj on a file-by-file basis, but GCC appears to hit the limit
on different files.
Fixes PR25953
llvm-svn: 290358
If OUTPUT_DIR is not specified we can assume the symlink is linking to a file in the same directory, so we can use $<TARGET_FILE_NAME:${target}> to create a relative symlink.
In the case of LLDB, when we build a framework, we are creating symlinks in a different directory than the file we're pointing to, and we don't install those links. To make this work in the build directory we can use $<TARGET_FILE:${target}> instead, which uses the full path to the target.
llvm-svn: 289840
This change enables building builtins for multiple different targets
using LLVM runtimes directory.
To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS
variable, where the value is the list of targets. To pass a per target
variable to the builtin build, you can set BUILTINS_<target>_<variable>
where <variable> will be passed to the builtin build for <target>.
Differential Revision: https://reviews.llvm.org/D26652
llvm-svn: 289491
It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool.
This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories.
This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR.
llvm-svn: 288770
This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators.
llvm-svn: 288679
Include component in install rules for Sphinx targets. Based on
a similar suggestion for other doc targets in D24935.
Differential Revision: https://reviews.llvm.org/D24982
llvm-svn: 288656
The old implementation of add_llvm_tool_symlink could fail in odd ways when building out of tree. This version solves that problem by not using the LLVM_* variables, and instead reaeding the target's properties.
llvm-svn: 288632
Add an optional parameter to `llvm_install_symlink` which allows the symlink
installation to be placed into a specific component rather than the default
value.
llvm-svn: 288600
This fixes a regression introduced by r285714: we weren't setting the
rpath on LLVMgold.so correctly.
Spotted by mark@chromium.org!
Differential Revision: https://reviews.llvm.org/D27176
llvm-svn: 288076
When LLVM_DEPENDENCY_DEBUGGING=On we should apply the sandbox only on the target, not the directory. This is important for directories that create more than one target, or for nested directories.
llvm-svn: 287415
Summary:
The motivation for this is to enable correct detection of dlopen() on Android.
Android does not provide a static version of libdl, so if we add the -static flag
after performing the check, it will succeed even though subsequent link steps
will fail. With this change we correctly detect the absence of libdl in a
LLVM_BUILD_STATIC build on Android.
The link itself still does not succeed because the code does not check the result
of this check properly, but I plan to fix that in a separate change.
Reviewers: beanz
Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits
Differential Revision: https://reviews.llvm.org/D26463
llvm-svn: 287220
This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen.
Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency.
llvm-svn: 287207
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for LLVM's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.
llvm-svn: 286209
Summary:
Set _install_rpath to CMAKE_INSTALL_RPATH if it is defined, so that eventually
INSTALL_RPATH is set to CMAKE_INSTALL_RPATH.
The "if(NOT DEFINED CMAKE_INSTALL_RPATH)" was missing a corresponding else
clause.
This also cleans up the fix made in r285908.
Patch by Azharuddin Mohammed
Reviewers: john.brawn, sgundapa, beanz
Subscribers: chapuni, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26289
llvm-svn: 286184
This Makes sure we only export targets that we're distributing, since
cmake will fail to import the file otherwise due to missing targets.
llvm-svn: 286024
r285714 made it so that when CMAKE_INSTALL_RPATH is set _install_rpath is not
set, but that means INSTALL_RPATH gets set to an empty string which isn't what
we want. Fix this by setting INSTALL_RPATH only when _install_rpath is set.
llvm-svn: 285908
This patch was produced in conjunction with Michał Górny. It should resolve the issues that were trying to be solved by D25304.
This moves rpath handling into `llvm_add_library` and `add_llvm_executable` so that it is available to all projects using AddLLVM whether built in-tree or out-of-tree.
llvm-svn: 285714
Summary:
This is temporary, until bot that builds public facing LLVM
documentation is upgraded. It reverts only the cmake change in r284497,
but leaves the doc changes in place to preserve intent.
Reviewers: aaron.ballman
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26078
llvm-svn: 285406
Summary:
The RFC proposal sent to increase the minimum required GCC version
to 4.8 received a lot of support. See the following thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105955.html,
This patch implements that by updating the docs. I believe the
references to libstdc++ 4.7 issues can be removed as well, please
let me know if that is not the case or if they should be updated
a different way.
Reviewers: rengolin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25683
llvm-svn: 284497
Make LIT_COMMAND configurable, use source tree only when actually
available and extend the default search to other common executable names
'lit.py' and 'lit', in order to increase uniformity between all LLVM
projects and support using installed lit.
Changing the conditional used to determine whether in-tree or external
lit is being used covers the case when LLVM_MAIN_SRC_DIR is defined but
does not exist (anymore). In this case, the functions falls back to
looking for installed lit rather than attempting to use a non-existing
path. The same conditional is used in clang already.
Making LIT_COMMAND a cache variable in case the source tree variant is
used serves two purposes. Firstly, it increases uniformity between
the two branches since find_program() implicitly makes LIT_COMMAND
a cache variable. Secondly, it allows overriding the lit executable used
to run the tests when the LLVM source tree is provided. Gentoo is
planning to use this to use installed (and byte-compiled) lit instead of
re-compiling it in every LLVM project.
Extending default search is meant to increase uniformity between
different LLVM projects. The 'lit.py' name is already used by a few of
them, and 'lit' is the name used by utils/lit/setup.py when installing.
Differential Revision: https://reviews.llvm.org/D25076
llvm-svn: 283247
CMake requires that all targets expressed as dependencies exist, so we can't have intrinsics_gen in LLVM_COMMON_DEPENDS when it is written out, otherwise projects building out of tree will have CMake errors.
llvm-svn: 283234
Reintroduce versioning of shared libraries via SOVERSION, addressing
the issues with the previous design, since Gentoo is relying
on shared-split install of LLVM. The SOVERSIONs were originally
introduced in r229720 for all libraries, and removed in r252093 in favor
of custom SONAME. As far as I understand, the major concern with the old
versioning was that the used versions were incompatible with ldconfig.
Having considered that, this commit introduce SOVERSIONS with the
following considerations:
1. SOVERSIONs are formed of major & minor version concatenated -- i.e.
for 4.0 its .so.40. This matches the common practice where the first
version number indicates ABI breakage, and therefore fixes the issues
with ldconfig. Additionally, VERSION with the remaining verion
components appended is used, however this is not strictly necessary.
2. The versioning is only applied to libraries with no explicit SONAME
specified -- i.e. it won't apply to libLLVM but only to the split
libraries. It will also apply to libraries installed by the subprojects.
3. The versioning is only done on *nix systems, Darwin excluded. This
matches the current use of SONAME.
Differential Revision: https://reviews.llvm.org/D24757
llvm-svn: 283189
Use separate doctrees between different Sphinx builders in order to
prevent race condition issues due to multiple Sphinx instances accessing
the same doctree cache in parallel.
Bug: https://llvm.org/bugs/show_bug.cgi?id=23781
Differential Revision: https://reviews.llvm.org/D23755
llvm-svn: 283188
Revert the change in r283029 (and the fixup in r283033) due to buildbot
breakage. The fixup is ineffective for the bots that do not force clean
build since the wrong value is already cached in CMakeCache.txt.
Reverting it should result in the cache variable being removed
and therefore it should be possible to re-introduce it after all
buildbots build this revision.
llvm-svn: 283036
Make LIT_COMMAND configurable, use source tree only when actually
available and extend the default search to other common executable names
'lit.py' and 'lit', in order to increase uniformity between all LLVM
projects and support using installed lit.
Changing the conditional used to determine whether in-tree or external
lit is being used covers the case when LLVM_MAIN_SRC_DIR is defined but
does not exist (anymore). In this case, the functions falls back to
looking for installed lit rather than attempting to use a non-existing
path. The same conditional is used in clang already.
Making LIT_COMMAND a cache variable in case the source tree variant is
used serves two purposes. Firstly, it increases uniformity between
the two branches since find_program() implicitly makes LIT_COMMAND
a cache variable. Secondly, it allows overriding the lit executable used
to run the tests when the LLVM source tree is provided. Gentoo is
planning to use this to use installed (and byte-compiled) lit instead of
re-compiling it in every LLVM project.
Extending default search is meant to increase uniformity between
different LLVM projects. The 'lit.py' name is already used by a few of
them, and 'lit' is the name used by utils/lit/setup.py when installing.
Differential Revision: https://reviews.llvm.org/D25076
llvm-svn: 283029
Install the OCaml interface .mli files. Those files were most likely
omitted because they are input files for the compiled .cmi files.
However, installing them is reasonable since -- unlike .cmi files --
they are human-readable.
The issue was originally spotted by @jpdeplaix.
Differential Revision: https://reviews.llvm.org/D25128
llvm-svn: 283028
Add a OCAML_INSTALL_PATH variable that can be used to control
the install path for OCaml libraries. The new variable defaults to
${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from
the OCaml compiler. Install libraries into "llvm" subdirectory.
This fixes two issues:
1. OCaml library directories differ between systems, and 'lib/ocaml' is
incorrect e.g. on amd64 Gentoo where OCaml is installed
in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml
compiler using 'ocamlc -where' (which is already used to set
OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages.
2. The top-level directory is reserved for the standard library, and has
precedence over local directory in search path. As a result, OCaml
preferred the files installed along with previous LLVM version over the
source tree when building a new version, resulting in two versions being
mixed during the build. The new layout is used commonly by other OCaml
packages, and findlib is able to find the LLVM libraries successfully.
Bug: https://bugs.gentoo.org/559134
Bug: https://bugs.gentoo.org/559624
Differential Revision: https://reviews.llvm.org/D24354
llvm-svn: 282895
When LLVM_INSTALL_TOOLCHAIN_ONLY is used and LLVM_TOOLCHAIN_TOOLS
contains a tool which is a symlink, it would be ignored. This already
worked before but got broken in r282510.
Differential Revision: https://reviews.llvm.org/D25067
llvm-svn: 282844
Summary:
The previous output was confusing as it would output "Taget triple:
x86_64-unknown-linux-gnu" even when LLVM_HOST_TRIPLE or
LLVM_DEFAULT_TARGET_TRIPLE were set on the CMake command line
Patch by: Alex Richardson!
Reviewers: beanz
Subscribers: Eugene.Zelenko
Differential Revision: https://reviews.llvm.org/D17067
llvm-svn: 282516
This supports creating symlinks to tools in different directories than
the tool is built to. This is useful for the LLDB framework build which
I’m sending patches for shortly.
llvm-svn: 281788
Summary:
When LLVM_LINK_LLVM_DYLIB is set, the libLLVM shared
library needs to be installed in the toolchain. Without
this chanage LLVM_INSTALL_TOOLCHAIN_ONLY combined with
LLVM_LINK_LLVM_DYLIB results in a broken install.
Patch by Sam Clegg
Differential Revision: https://reviews.llvm.org/D24676
llvm-svn: 281763
Previously, gtest/gtest_main were not exported via cmake. The intention here was
to ensure that users whom are linking against the LLVM install tree would not
get the gtest/gtest_main targets. This prevents downstream projects that link
against the LLVM build tree (i.e. Swift) from getting this dependency
information in their cmake builds. Without such dependency information, linker
issues can result on linux due to LLVMSupport being put before gtest on the
linker command line.
This commit preserves behavior that we want for the install tree, while adding
support for the build tree by:
1. The special casing for gtest/gtest_main in the add_llvm_library code is
removed in favor of a flag called "BUILDTREE_ONLY". If this is set, then the
library is communicating that it is only meant to be exported into the build
tree and is not meant to be installed or exported via the install tree. This
part is just a tweak to remove the special case, the underlying code is the
same.
2. The cmake code that exports cmake targets for the build tree has special code
to import an additional targets file called
LLVMBuildTreeOnlyExports.cmake. Additionally the extra targets are added to the
LLVMConfig.cmake's LLVM_EXPORTED_TARGETS variable. In contrast, the
"installation" cmake file uses the normal LLVM_EXPORTS_TARGETS as before and
does not include the extra exports file. This is implemented by
defining/undefining variables when performing a configure of the build/install
tree LLVMConfig.cmake files.
llvm-svn: 281085
Zachary Turner