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
Reapply "Set a different var for checking I686, because LLVM_NATIVE_ARCH is"
This reverts commit e7400d7cbc2b7539de3aa7a20adc8f4ee0cb7bef.
llvm-svn: 309181
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: Implement parsing and writing of a single xml manifest file.
Subscribers: mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35425
llvm-svn: 308679
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
On FreeBSD backtrace is not part of libc and depends on libexecinfo
being available. Instead of using manual checks we can use the builtin
CMake module FindBacktrace.cmake to detect availability of backtrace()
in a portable way.
Patch By: Alex Richardson
Differential Revision: https://reviews.llvm.org/D27143
llvm-svn: 300062
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
The function for distinguishing local and remote files added in r295768
unconditionally uses linux/magic.h header to provide necessary
filesystem magic numbers. However, in kernel headers predating 2.6.18
the magic numbers are spread throughout multiple include files.
Furthermore, LLVM did not require kernel headers being installed so far.
To increase the portability across different versions of Linux kernel
and different Linux systems, add CMake header checks for linux/magic.h
and -- if it is missing -- the linux/nfs_fs.h and linux/smb.h headers
which contained the numbers previously.
Furthermore, since the numbers are static and the feature does not seem
critical enough to make LLVM require kernel headers at all, add fallback
constants for the case when none of the necessary headers is available.
Differential Revision: https://reviews.llvm.org/D30261
llvm-svn: 295854
This is useful for some edge cases where detecting things gets tricky. Specifically LLDB needs this to support iOS because CMake doesn't support running tests using obj-c code.
llvm-svn: 295392
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
This was previously searched in CMakeLists.txt unconditionally but as of
r294371 it is only searched in some circumstances. Repeating the search
in config-ix.cmake to make this robust and hopefully fix the macOS
Asan+Ubsan jenkins build.
llvm-svn: 294811
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
Committing after fixing suggested changes and tested release/debug builds on
x86_64-linux and arm/aarch64 builds.
Differential revision: https://reviews.llvm.org/D29042
llvm-svn: 293850
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
Using sigaltstack on Apple platforms is a bad idea. Darwin's backtrace()
function does not work with sigaltstack, and my change in r286851 was
supposed to solve that by using _Unwind_Backtrace instead. I tested that
_Unwind_Backtrace works for crashes but then discovered that it does not
work for assertion failures when using sigaltstack, at least on macOS.
The stack trace shows only the frames on the alternate stack.
I also saw some reports of this happening for crashes, but it fails
consistently for assertion failures. I tried various things to get it to
work but the problem seems to be in _Unwind_Backtrace itself. Disabling
sigaltstack is unfortunate since it would be nice to get backtraces for
stack overflows, but at least this gets us backtraces for the more common
cases. rdar://problem/29662459
llvm-svn: 291206
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
This required re-working the streaming support and lit's support for
'--gtest_list_tests' but otherwise seems to be a clean upgrade.
Differential Revision: https://reviews.llvm.org/D28154
llvm-svn: 291029
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: This should provide the function similar to `--disable-libedit` with the autotools build system, which seems to be missing from the commit (r200595) that adds this.
Reviewers: pcc, beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26550
llvm-svn: 287293
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
This cleanup removes the need for the native support library to have its own target. That target was only needed because makefile builds were tripping over each other if two tablegen targets were building at the same time. This causes problems because the parallel make invocations through CMake can't communicate with each other. This is fixed by invoking make directly instead of through CMake which is how we handle this in External Project invocations.
The other part of the cleanup is to mark the custom commands as USES_TERMINAL. This is a bit of a hack, but we need to ensure that Ninja generators don't invoke multiple tablegen targets in the same build dir in parallel, because that too would be bad.
Marking as USES_TERMINAL does have some downside for Ninja because it results in decreased parallelism, but correct builds are worth the minor loss and LLVM_OPTIMZIED_TABLEGEN is such a huge win, it is worth it.
llvm-svn: 280748
This adds a copy of the demangler in libcxxabi.
The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.
The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:
No constexpr.
No alignas
On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi
My current plan is:
Commit something like this
Change lld to use it
Change lldb to use it as the fallback
Add a few #ifdefs so that exactly the same file can be used in
libcxxabi to export abi::__cxa_demangle.
Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.
llvm-svn: 280732
That is, add build system support for building the OCaml bindings
against preinstalled LLVM libraries. This is important for package
managers such as OPAM, because OCaml libraries need to be built
against a specific OCaml compiler installation.
llvm-svn: 280642
This is a partial revert of r280013. Brad King pointed out these variable names are matching CMake conventions, so we should preserve them.
I've also added a direct mapping of the LLVM_*_DIR variables which we need to make projects support building in and out of tree.
llvm-svn: 280380
With the runtimes build we're trying to use LLVMConfig.cmake as a way of providing LLVM_* variables that are needed to behave as if the project is building in tree. To make this work we need to rename two variables by dropping the "S" from the end. This makes the variables match the in-tree names.
This renames:
LLVM_INCLUDE_DIRS -> LLVM_INCLUDE_DIR
LLVM_LIBRARY_DIRS -> LLVM_LIBRARY_DIR
The versions ending in S are not used in-tree anywhere. This also cleans up LLVM_LIBRARY_DIR being set to the same value with and without the "S".
llvm-svn: 280013
Summary:
Install CheckAtomic.cmake along with other LLVM modules, therefore making it possible for other projects to use it. This file is needed for LLDB to be built standalone, and installing it was suggested in https://reviews.llvm.org/D23881.
Patch by: Michał Górny
Reviewers: krytarowski, zturner, eugenis, jyknight, labath, beanz
Subscribers: beanz, llvm-commits
Differential Revision: https://reviews.llvm.org/D23887
llvm-svn: 279777
Summary: Asan fails to UnsetAlternateSignalStack if it set by Unix/Signals.inc
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23864
llvm-svn: 279717
The subproject interface being used for runtime libraries expects that llvm-config is passed into the subproject for consumption. We currently do this for every subproject, so we should expect that all LLVM ExternalProjects depend on llvm-config for the time being.
Eventually I'd like to see the sub-projects using LLVMConfig.cmake instead of the llvm-config binary, but that will take time to roll out.
llvm-svn: 279155
Summary:
To build llgo, you must currently ensure that llgo
is in the tools/llgo directory, due to a hard-coded
path in llvm-go.
To support the use of LLVM_EXTERNAL_LLGO_SOURCE_DIR,
we introduce a flag to llvm-go that enables the
caller to specify the paths to symlink in the
temporary $GOPATH.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D21634
llvm-svn: 276829
Given similar reasons from r276710, ld64 scrubs DYLD_* environment if
called from the shim executable /usr/bin/ld.
Add support for finding ld64 via xcrun.
This is needed in order to get LIT to have the full path to the ld4
executable.
Differential Revision: https://reviews.llvm.org/D22791
rdar://problem/24300926
llvm-svn: 276781
With in-tree builds we can get Output directories scattered among our
tests. Recursing into those to find tests doesn't make sense.
Thanks to nlewycky for noticing this!
llvm-svn: 276667
This makes sure that space is actually available. With this change
running lld on a full file system causes it to exit with
failed to open foo: No space left on device
instead of crashing with a sigbus.
llvm-svn: 276017
This option is the equivalent option to LLVM_BUILD_TOOLS but for executables
created via add_llvm_utility.
This is a useful tool for improving compile time in situations where LLVM is
used as a library and no testing tools are needed.
It follows the exact same implemention model as LLVM_BUILD_TOOLS.
Since the option is by default set to on, no behavior is changed unless one sets
it from the command line to be false.
llvm-svn: 275007
export_executable_symbols looks though the link libraries of the executable in
order to figure out transitive dependencies, but in doing so it assumes that
all link libraries are also targets. This is not true as of r273302, so adjust
it to check if they actually are targets.
llvm-svn: 274546
Previously out-of-tree passes could detect if LLVM was built with
LLVM_BUILD_32_BITS by looking for -m32 in LLVM_DEFINITIONS, but as of r271871
it no longer appears there. Resolve this by instead emitting LLVM_BUILD_32_BITS
in LLVMConfig so it can be checked for directly.
Differential Revision: http://reviews.llvm.org/D21434
llvm-svn: 274351
This reverts commit 3db82f646a0890eb7664d0351b5a3c79622e8bef.
Vassil already fixed this and I mechanically undid his fix without looking
too close at what I'm actually doing. Need more coffee.
llvm-svn: 274242
This fixes a typo introduced in r274196.
Thanks to Vassil Vassilev for noticing!
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274240
On Darwin it is currently impossible to build LLVM with modules
because the Darwin system module map is not compatible with
-fmodules-local-submodule-visibility at this point in time. This
patch makes the flag optional and off by default on Darwin so it
becomes possible to build LLVM with modules again.
http://reviews.llvm.org/D21827
rdar://problem/27019000
llvm-svn: 274196
This is just a small step in the direction of making LLVMConfig.cmake a complete
replacement for llvm-config.
For those unfamiliar, llvm-config --build-mode prints out CMAKE_BUILD_TYPE. Thus
as one can imagine, LLVM_BUILD_TYPE is @CMAKE_BUILD_TYPE@.
llvm-svn: 273782
Summary:
There are a few LLVM projects that produce runtime libraries. Ideally
runtime libraries should be built differently than other projects,
specifically they should be built using the just-built toolchain.
There is support for building compiler-rt in this way from the clang
build. Moving this logic into the LLVM build is interesting because it
provides a simpler way to extend the just-built toolchain to include
LLD and the LLVM object file tools.
Once this functionality is better fleshed out and tested we’ll want to
encapsulate it in a module that can be used for clang standalone
builds, and we’ll want to make it the default way to build compiler-rt.
With this patch applied there is no immediate change in the build.
Moving compiler-rt out from llvm/projects into llvm/runtimes enables
the functionality.
This code has a few improvements over the method provided by
LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is
always invoked, so changes to compiler-rt source files will get built
properly, so this patch can be used for iterative development with
just-built tools.
This first patch only works with compiler-rt. Support for other
runtime projects will be coming in follow-up patches.
Reviewers: chandlerc, bogner
Subscribers: kubabrecka, llvm-commits
Differential Revision: http://reviews.llvm.org/D20992
llvm-svn: 273620
Patch by Nitesh Jain.
Summary: On some target like MIPS32 we need to explicitly link atomic library for 64 bit atomic operations. This module then can be used in LLDB (http://reviews.llvm.org/D20464) or Libcxx (http://reviews.llvm.org/D16613) for explicitly link to atomic library.
Reviewers: chandlerc, beanz
Differential: reviews.llvm.org/D20896
llvm-svn: 273534
LLVMConfig.cmake needs to set LLVM_BINARY_DIR differently based on whether or not it is the build directory or the install directory. The build directory just needs to set the value from the configuration, the install directory needs to set it to the install prefix.
llvm-svn: 273479
Otherwise it gets linked in by one of the dependencies of shared
libraries which may be too late and we end up with weird crashes in
std::call_once().
Differential Revision: http://reviews.llvm.org/D21478
llvm-svn: 273302
This is the more-correct fix to out-of-tree building. AddLLVM.cmake relies on this variable being set, so we should make sure it is set in LLVMConfig.cmake.
llvm-svn: 272279
