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
Reid Kleckner