Summary:
Related to D75672, this patch adds EVT::isFixedLengthVector to determine
if the underlying vector type is of fixed length.
An assert is introduced in EVT::getVectorNumElements that triggers for
types that aren't fixed length. This is currently guarded by a flag
added D75297 that is off by default and has been renamed to the more
generic ENABLE_STRICT_FIXED_SIZE_VECTORS.
Ideally we want to get rid of getVectorNumElements but a quick grep
shows there are >350 uses in lib/CodeGen and 75 in lib/Target/AArch64
alone. All of these probably aren't EVT::getVectorNumElements (some may
be the MVT equivalent), but there are many places to fixup and having
the assert on by default would make the SVE upstreaming effort
difficult.
Reviewers: sdesmalen, efriedma, ctetreau, huntergr, rengolin
Reviewed By: efriedma
Subscribers: mgorny, kristof.beyls, hiraditya, danielkiss, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76376
This patch removes compiler runtime assertions that ensure the implicit
conversion are only guaranteed to work for fixed-width vectors.
With the assert it would be impossible to get _anything_ to build until
the
entire codebase has been upgraded, even when the indiscriminate uses of
the size as uint64_t would work fine for both scalable and fixed-width
types.
This issue will need to be addressed differently, with build-time errors
rather than assertion failures, but that effort falls beyond the scope
of this patch.
Returning the scalable size and avoiding the assert in getFixedSize()
is a temporary stop-gap in order to use LLVM for compiling and using
the SVE ACLE intrinsics.
Reviewers: efriedma, huntergr, rovka, ctetreau, rengolin
Reviewed By: efriedma
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75297
Summary:
Add FORCE_ON option to LLVM_ENABLE_ZLIB, which causes a configuration
error if zlib is not found.
Similar to https://reviews.llvm.org/D40050.
Reviewers: hans, thakis, rnk
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76110
Summary:
This is an attempt to simply the process of building the clang
documentation, which should help avoid some of the recent issues we've
had generating the documentation for the website.
The html documentation for clang is generated by sphinx from the
reStructuredText (rst) files we have in the clang/docs directory.
There are also some rst files that need to be generated by TableGen,
before they can be passed to sphinx. Prior to this patch we were not
generating those rst files as part with the build system and they had to be
generated manually.
This patch enables the automatic generation of these rst files, but
since they are generated at build time the cannot be placed in the
clang/docs directory and must go into the cmake build directory.
Unfortunately sphinx does not currently support multiple source
directories[1], so in order to be able to generate the full
documentation, we need to work around this by copying the
rst files from the clang/docs into the build directory before
generating the html documentation.
[1] https://github.com/sphinx-doc/sphinx/issues/3132
Reviewers: rsmith, aaron.ballman, beanz, smeenai, phosek, compnerd, mgorny, delcypher
Reviewed By: mgorny, delcypher
Subscribers: delcypher, merge_guards_bot, mgorny, llvm-commits, cfe-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D72875
and follow-ups:
a2ca1c2d "build: disable zlib by default on Windows"
2181bf40 "[CMake] Link against ZLIB::ZLIB"
1079c68a "Attempt to fix ZLIB CMake logic on Windows"
This changed the output of llvm-config --system-libs, and more
importantly it broke stand-alone builds. Instead of piling on more fix
attempts, let's revert this to reduce the risk of more breakages.
Summary:
Enabling _GLIBCXX_DEBUG (implied by LLVM_ENABLE_EXPENSIVE_CHECKS) causes
std::min_element (and presumably others) to no longer be constexpr, which
in turn causes the build to fail.
This seems like a bug in the GCC STL. This change works around it.
Change-Id: I5fc471caa9c4de3ef4e87aeeac8df1b960e8e72c
Reviewers: tstellar, hans, serge-sans-paille
Differential Revision: https://reviews.llvm.org/D75199
Using INTERFACE prevents the use of imported libraries as we've done
in 00b3d49 because these aren't linked against the target, they're
only made part of the interface. This doesn't affect the output since
static libraries aren't being linked into, but it enables the use of
imported libraries.
Differential Revision: https://reviews.llvm.org/D74106
Summary:
- Add `-gsplit-dwarf` as an option instead of a definition.
- Only add that option on compilers supporting dwarf splitting, such as clang
and gcc.
Reviewers: echristo, pcc
Subscribers: mgorny, aprantl, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75328
Pass plugins introduced in D61446 do not support dynamic linking on
Windows, hence the option LLVM_${name_upper}_LINK_INTO_TOOLS can only
work being set to "ON". Currently, it defaults to "OFF" such that such
plugins are inoperable by default on Windows. Change the default for
subprojects to follow LLVM_ENABLE_PROJECTS.
Reviewed By: serge-sans-paille, MaskRay
Differential Revision: https://reviews.llvm.org/D72372
Summary:
AIX supports both 32-bit and 64-bit environments (with 32-bit being the default). This patch improves support for building LLVM on AIX in both 32-bit and 64-bit mode.
- Change host detection to return correct 32/64-bit triple as config_guess does not return the correct version on 64-bit. This can confuse JIT tests and other things that care about what the host triple is.
- Remove manual setting of 64-bit flags on AIX. AIX provides OBJECT_MODE environment variable to enable the user to obtain a 64-bit development environment. CMake will properly set these flags provided the user sets the correct OBJECT_MODE before configuring and setting them manually will interfere with 32-bit builds.
- Don't present the LLVM_BUILD_32_BITS option on AIX, users should use OBJECT_MODE when running CMake instead.
Reviewers: hubert.reinterpretcast, DiggerLin, stevewan
Reviewed By: DiggerLin, stevewan
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74256
Use a dedicated cmake file to store the extension configured within LLVM. That
way, a standalone build of clang can load this cmake file and get all the
configured standalone extensions.
This patch is related to https://reviews.llvm.org/D74602
Differential Revision: https://reviews.llvm.org/D74757
Summary:
Otherwise, the build output contains a bunch of "Linker detection: <xxx>"
lines that are really redundant. We also make redundant calls to the
linker, although that is a smaller concern.
Reviewers: smeenai
Subscribers: mgorny, fedor.sergeev, jkorous, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68648
The check for 'HAVE_CXX_ATOMICS_WITHOUT_LIB' may create false
positives in RISC-V. This is reproducible when compiling LLVM natively
using GCC on a rv64gc (rv64imafdgc) host. Due to the 'A' (atomic)
extension, g++ replaces calls to libatomic operations on the
std::atomic<int> type with the native hardware instructions. As a
result, the compilation succeeds and the build system thinks it
doesn't need to pass '-latomic'.
Improve the reliability of the 'HAVE_CXX_ATOMICS_WITHOUT_LIB' test in
two steps:
1. Force a pre-increment on x (++x), which should force a call to a
libatomic function;
2. Because step 1 would resolve the increment to 'amoadd.w.aq' under
the 'A' extension, force the same operation on sub-word types, for
which there is no hardware support.
Reviewers: jfb, hintonda, smeenai, mgorny, JDevlieghere, jyknight
Reviewed By: jfb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68964
We were skipping the libatomic requirement check for MSVC, but not setting
the corresponding variable, HAVE_CXX_ATOMICS_WITHOUT_LIB. D69869 seems to
have to failed to build on ARM MSVC because of that, and was reverted. This
should probably fix the issue. The plan is to check the result of the build
bots and then submit a more thoroughly refactored version for review.
This is like -fdata-sections, and it's not part of /O2 by default for some reason.
In the cmake build, reduces the size of clang.exe from 70,358,016 bytes to 69,982,720 bytes.
clang-format.exe goes from 3,703,296 bytes to 3,331,072 bytes.
Differential Revision: https://reviews.llvm.org/D74573
Summary: LLVM configuration fails with 'unable to guess system type' on riscv64.
Add support for detecting riscv32 and riscv64 systems.
Patch by Gokturk Yuksek (gokturk)
Reviewers: erichkeane, rengolin, mgorny, aaron.ballman, beanz, luismarques
Reviewed By: luismarques
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68899
This reduces the reliance on host tools and makes the build more
hermetic. Some of the runtimes already assume that certain tools are
always available, for example libc++ and libc++abi archive merging
relies on ar to extract files out of the archive, even on Darwin.
Differential Revision: https://reviews.llvm.org/D74107
EXCLUDE_FROM_ALL means something else for add_lit_testsuite as it does
for something like add_executable. Distinguish between the two by
renaming the variable and making it an argument to add_lit_testsuite.
Differential revision: https://reviews.llvm.org/D74168
The change in 9b84dabc5f36f7e027c62b5c00ea97e21cfcacdd uses a newer
syntax which not all the builders support. Use an explicit `OR` over
the languages instead to repair the builders.
This patch limits adding -UNDEBUG to C and C++ files so that projects
can include files compiled with compilers that don't recognize this
argument (Swift e.g.).
add_definitions does not expand generators, hence the change from
add_definitions to add_compile_options.
Patch by Evan Wilde!
This allows consumer to override in a cleaner way while still prevent
them from hitting bug without knowing they run an unsupported
configuration.
Recommit after fix by Christopher Tetreault to add parens and ${} to
cmake check to work around CMake configure time "unknown arguments
specified" issue
Differential Revision: https://reviews.llvm.org/D73677
Differential Revision: https://reviews.llvm.org/D73751
This allows consumer to override in a cleaner way while still prevent
them from hitting bug without knowing they run an unsupported
configuration.
Differential Revision: https://reviews.llvm.org/D73677
This is necessary on Windows, otherwise CMake fails. It's not
conventional on Windows to use cl for assembly (you'd use ml or ml64
instead), but CMake has a separate ASM_MASM mode for that, and clang-cl
works fine for assembly so we'll use that on Windows for consistency.
Differential Revision: https://reviews.llvm.org/D73522
This changes the generated (Instr|Asm|Reg|Regclass)Name tables from this
form:
extern const char HexagonInstrNameData[] = {
/* 0 */ 'G', '_', 'F', 'L', 'O', 'G', '1', '0', 0,
/* 9 */ 'E', 'N', 'D', 'L', 'O', 'O', 'P', '0', 0,
/* 18 */ 'V', '6', '_', 'v', 'd', 'd', '0', 0,
/* 26 */ 'P', 'S', '_', 'v', 'd', 'd', '0', 0,
[...]
};
...to this:
extern const char HexagonInstrNameData[] = {
/* 0 */ "G_FLOG10\0"
/* 9 */ "ENDLOOP0\0"
/* 18 */ "V6_vdd0\0"
/* 26 */ "PS_vdd0\0"
[...]
};
This should make debugging and exploration a lot easier for mortals,
while providing a significant compile-time reduction for common compilers.
To avoid issues with low implementation limits, this is disabled by
default for visual studio.
To force output one way or the other, pass
`--long-string-literals=<bool>` to `tablegen`
Reviewers: mstorsjo, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D73044
A variation of this patch was originally committed in ce23515f5ab011 and
then reverted in e464b31c due to build failures.
This changes the generated (Instr|Asm|Reg|Regclass)Name tables from this
form:
extern const char HexagonInstrNameData[] = {
/* 0 */ 'G', '_', 'F', 'L', 'O', 'G', '1', '0', 0,
/* 9 */ 'E', 'N', 'D', 'L', 'O', 'O', 'P', '0', 0,
/* 18 */ 'V', '6', '_', 'v', 'd', 'd', '0', 0,
/* 26 */ 'P', 'S', '_', 'v', 'd', 'd', '0', 0,
[...]
};
...to this:
extern const char HexagonInstrNameData[] = {
/* 0 */ "G_FLOG10\0"
/* 9 */ "ENDLOOP0\0"
/* 18 */ "V6_vdd0\0"
/* 26 */ "PS_vdd0\0"
[...]
};
This should make debugging and exploration a lot easier for mortals,
while providing a significant compile-time reduction for common compilers.
To avoid issues with low implementation limits, this is disabled by
default for visual studio or when cross-compiling.
To force output one way or the other, pass
`--long-string-literals=<bool>` to `tablegen`
Reviewers: mstorsjo, rnk
Subscribers: llvm-commit
Differential Revision: https://reviews.llvm.org/D73044
It's been an empty target since r360498 and friends
(`git log --grep='Move InstPrinter files to MCTargetDesc.' llvm/lib/Target`),
but due to hwo the way these targets are structured it was silently
an empty target without anyone noticing.
No behavior change.
When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no
longer embedded into binaries (mostly for --version output).
Without it, most binaries need to relink after every single
commit, even if they didn't change otherwise (due to, say,
a documentation-only commit).
LLVM_APPEND_VC_REV is ON by default, so this doesn't change the
default behavior of anything.
With this, all clients of GenerateVersionFromVCS.cmake honor
LLVM_APPEND_VC_REV.
Differential Revision: https://reviews.llvm.org/D72855
Summary:
The IBM XL compiler uses `-qfuncsect` for `-ffunction-sections`.
The comment about sanitizers and `-f[no-]function-sections` is corrected
also, as it is pertinent to this patch.
The sanitizer-related use of `-fno-function-sections` is associated with
powerpc64le, a target for which there is an IBM XL compiler, so that use
is updated in this patch to apply `-qnofuncsect` in case a build using
the XL compiler is viable on that platform.
This patch has been verified with the XL compiler on AIX only.
Reviewers: daltenty, stevewan
Reviewed By: daltenty
Subscribers: mgorny, steven.zhang, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D72335
- Update documentation now that the move to monorepo has been made
- Do not tie compiler extension testing to LLVM_BUILD_EXAMPLES
- No need to specify LLVM libraries for plugins
- Add NO_MODULE option to match Polly specific requirements (i.e. building the
module *and* linking it statically)
- Issue a warning when building the compiler extension with
LLVM_BYE_LINK_INTO_TOOLS=ON, as it modifies the behavior of clang, which only
makes sense for testing purpose.
Still mark llvm/test/Feature/load_extension.ll as XFAIL because of a
ManagedStatic dependency that's going to be fixed in a seperate commit.
Differential Revision: https://reviews.llvm.org/D72327
https://reviews.llvm.org/D61446 introduced a new function to process
pass plugins that used CMAKE_BINARY_DIR. This is problematic when LLVM
is a subproject. Instead use LLVM_BINARY_DIR to get the right relative
directory for cmake.
Patch by Alan Baker <alanbaker@google.com>
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D72109
The install-${name}-stripped targets don't strip when ${name} is being
symlinked, e.g. llvm-ar or llvm-objcopy. The problem is that
llvm_install_symlink passes install-${dest} as a dependency of
install-${name}, e.g. install-llvm-ar becomes a dependency of both
install-llvm-ranlib and install-llvm-ranlib-stripped. What this means is
that when installing a distribution that contains both llvm-ar and
llvm-ranlib is that first the stripped version of llvm-ar is installed
(by the install-llvm-ar-stripped target) and then it's overwritten by an
unstripped version of llvm-ar bnecause install-llvm-ranlib-stripped has
install-llvm-ranlib as a dependency as mentioned earlier. To avoid this
issue, rather than passing the install-${dest} as dependency, we
introduce a new argument to add_llvm_install_targets for symlink target
which expands it into an appropriate dependency, i.e. install-${dest}
for install-${name} target and install-${dest}-stripped for
install-${name}-stripped.
Differential Revision: https://reviews.llvm.org/D71951
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28,
e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. The problem with the windows
bot is a need for clearing the cache.
This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28.
This commit broke the clang-x64-windows-msvc build bot and a follow-up
commit did not fix it. Reverting to fix the bot.
This reverts commit e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad.
This commit was an attempt to fix the build bots, but it still left the
clang-x64-windows-msvc bot in a broken state.
There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly could be useful to other external
projects: thanks to that mechanism it would be possible to develop LLVM
extension without touching the LLVM code base.
This patch has two effects:
1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it
with a generic mechanism
2. Provide a generic mechanism to register compiler extensions.
A compiler extension is similar to a pass plugin, with the notable difference
that the compiler extension can be configured to be built dynamically (like
plugins) or statically (like regular passes).
As a result, people willing to add extra passes to clang/opt can do it using a
separate code repo, but still have their pass be linked in clang/opt as built-in
passes.
Differential Revision: https://reviews.llvm.org/D61446
Treat the flag `LLVM_ENABLE_ZLIB` as a tri-bool, `FORCE_ON` being `ON`,
and `ON` being an auto-detect. This is needed as many of the builders
enable the flag without having zlib available.
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencies lists.
Reviewers: alexshap, beanz, phosek, compnerd, smeenai, mtrent, plotfi, xiaobai
Reviewed By: phosek, smeenai
Subscribers: smeenai, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71429
Summary:
export_symbols.py discards duplicate symbols, assuming they have public definitions, so if we end
up calling it with duplicate libraries we will end up with an inaccurate export list.
Reviewers: jasonliu, stevewan, john.brawn
Reviewed By: john.brawn
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70918
Summary:
This new warning (enabled by -Wextra) fires when a std::move is
redundant, as the default compiler behavior would be to select a move
operation anyway (e.g., when returning a local variable). Unlike
-Wpessimizing-move, it has no performance impact -- it just adds noise.
Currently llvm has about 1500 of these warnings. Unfortunately, the
suggested fix -- removing std::move -- does not work because of some
older compilers we still support. Specifically clang<=3.8 will not use a
move operation if an implicit conversion is needed (Core issue 1579). In
code like "A f(ConvertibleToA a) { return a; }" it will prefer a copy,
or fail to compile if a copy is not possible.
This patch disables that warning to get a meaningful signal out of a GCC
9 build.
Reviewers: rnk, aaron.ballman, xbolva00
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70963
This reverts commit 2e75681b55ab55301022533b203269f5f3d6f909. Restore
the clean up change. The underlying CMake issue was resolved in
372ad32734ecb455f9fb4d0601229ca2dfc78b66.
as it breaks uses of llvm-config --system-libs and the follow-on commit
"build: avoid cached literals being linked against"
This reverts commits 340e7c0b77a7037afefe7255503afe362967b577 and
340e7c0b77a7037afefe7255503afe362967b577.
FindLibXml2 will set the LIBXML2_LIBRARIES variable to the libraries that
we must link against. This will be an empty string if libxml2 is not
found. Avoid hardcoding the library name as xml2 in the configuration.
Simplify the usage in the WindowsManifest library.
On RHEL, the OS tooling (ar, ranlib) is not deterministic by default.
Therefore, we cannot get bit-for-bit identical builds.
The goal of this patch is that it adds the flags required to force determinism.
Differential Revision: https://reviews.llvm.org/D64817
Summary:
Most libraries are defined in the lib/ directory but there are also a
few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining
"Component Libraries" as libraries defined in lib/ that may be included in
libLLVM.so. Explicitly marking the libraries in lib/ as component
libraries allows us to remove some fragile checks that attempt to
differentiate between lib/ libraries and tools/ libraires:
1. In tools/llvm-shlib, because
llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of
all libraries defined in the whole project, there was custom code
needed to filter out libraries defined in tools/, none of which should
be included in libLLVM.so. This code assumed that any library
defined as static was from lib/ and everything else should be
excluded.
With this change, llvm_map_components_to_libnames(LIB_NAMES, "all")
only returns libraries that have been added to the LLVM_COMPONENT_LIBS
global cmake property, so this custom filtering logic can be removed.
Doing this also fixes the build with BUILD_SHARED_LIBS=ON
and LLVM_BUILD_LLVM_DYLIB=ON.
2. There was some code in llvm_add_library that assumed that
libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or
ARG_LINK_COMPONENTS set. This is only true because libraries
defined lib lib/ use LLVMBuild.txt and don't set these values.
This code has been fixed now to check if the library has been
explicitly marked as a component library, which should now make it
easier to remove LLVMBuild at some point in the future.
I have tested this patch on Windows, MacOS and Linux with release builds
and the following combinations of CMake options:
- "" (No options)
- -DLLVM_BUILD_LLVM_DYLIB=ON
- -DLLVM_LINK_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON
- -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON
Reviewers: beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70179
The mlir-tblgen tool was not getting installed. This change allows
the MLIR project to be installed along with llvm-tblgen.
Differential Revision: https://reviews.llvm.org/D69824
Projects that set LLVM_TARGETS_TO_BUILD to an empty list
can't use add_llvm_tool (and probably other macros).
Here's the error that this change fixes:
list sub-command REMOVE_ITEM requires two or more arguments.
https://reviews.llvm.org/D70167
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
Summary:
This makes it look like an elseif and also the variable referenced
in the condition was removed from this function in r366622.
Reviewers: dsanders, beanz, smeenai, compnerd, phosek
Reviewed By: beanz
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70159
Summary:
when building plugins, as AIX has symbols in it's standard library that
must be garbage collected or we will see link errors. Export lists will
handle this instead on AIX.
Reviewers: stevewan, sfertile, jasonliu, xingxue, DiggerLin
Reviewed By: DiggerLin
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70130
Summary:
this allows us to move logic about when it is appropriate set
LLVM_NO_DEAD_STRIP out of each tool and into add_llvm_executable,
which will enable future platform specific handling.
This is a follow on to the reverted D69356
Reviewers: hubert.reinterpretcast, beanz, lhames
Reviewed By: beanz
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D69638
Also add the aliases for these tools so that
LLVM_INSTALL_BINUTILS_SYMLINKS and LLVM_INSTALL_TOOLCHAIN_ONLY can work
together.
Differential Revision: https://reviews.llvm.org/D69635
This extension point is not needed. Provide the equivalent option
through `CMAKE_CXX_STANDARD` which mirrors the previous extension point. Rely on
CMake to provide the check for the compiler instead.
Summary:
The variable LLVM_NO_DEAD_STRIP is set in LLVM cmake files when building executables that might make use of plugins .The name of the variable does not convey the actual intended usage (i.e. for use with tools that have plugins), just what the eventual effect of setting in on some (i.e. not garbage collecting unused symbols).
This patch renames it to LLVM_SUPPORT_PLUGINS to convey the intended usage, which will allow subsequent patches to add behavior to support that in different ways without confusion about whether it will do on, for example, non-gnu platforms.
Reviewers: hubert.reinterpretcast, stevewan
Reviewed By: stevewan
Subscribers: cfe-commits, mgorny, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D69356
We're passing LLVM_EXTERNAL_PROJECTS to cross-compilation configures, so
we also need to pass the source directories of those projects, otherwise
configuration can fail from not finding them.
Differential Revision: https://reviews.llvm.org/D69076
llvm-svn: 375157
Support linking OCaml modules against LLVM dylib when requested,
rather than against static libs that might not be installed at all.
Differential Revision: https://reviews.llvm.org/D68452
llvm-svn: 374556
Move the write-if-changed logic behind a flag and don't pass it
with the MSVC generator. msbuild doesn't have a restat optimization,
so not doing write-if-change there doesn't have a cost, and it
should fix whatever causes PR43385.
llvm-svn: 373664
Add install targets as necessary to include all files normally installed
in LLVM_DISTRIBUTION_COMPONENTS. This includes targets for Sphinx docs,
opt-viewer Python modules and TableGens.
Differential Revision: https://reviews.llvm.org/D68339
llvm-svn: 373482
Differential Revision: https://reviews.llvm.org/D55842
-----------------
As discussed on PR43385 this is causing Visual Studio msbuilds to perpetually rebuild all tablegen generated files
llvm-svn: 373338
Serialize the value of the configuration option into the configuration so that
builds which integrate LLVM can identify the value of the flag that was used to
build the libraries. This is intended to be used by Swift to control tests
which rely on the unwind information.
llvm-svn: 373253
Mimics the changes in r372209 to handle the change of quotes in
r372226. Probably isn't sufficient for windows, but unbreaks the cmake
flag at least.
llvm-svn: 372791
Modify LLVMConfig to produce LLVM_USE_CRT variables in build-directory. It helps to set the same compiler debug options like in builded library.
Committed on behalf of @igorban (Igor)
Differential Revision: https://reviews.llvm.org/D67175
llvm-svn: 372610
Fixes quoting of profile arguments to work on Windows
Suppresses adding profile arguments to linker flags when using lld-link
Avoids -fprofile-instr-use being added to rc.exe flags
Removes duplicated adding of -fprofile-instr-use to linker flags (since
r355541)
Move handling LLVM_PROFDATA_FILE to HandleLLVMOptions.cmake
Differential Revision: https://reviews.llvm.org/D62063
llvm-svn: 372209
Tested on VS2017 and VS2019 llvm/clang builds with WX enabled - its no longer necessary to disable this warning.
Differential Revision: https://reviews.llvm.org/D67103
llvm-svn: 370871
Tested on VS2017 and VS2019 llvm/clang builds with WX enabled - its no longer necessary to disable this warning.
Differential Revision: https://reviews.llvm.org/D67047
llvm-svn: 370866
In r370135 I committed a temporary workaround for the sanitized bot to
not set (DY)LD_LIBRARY_PATH when (DY)LD_INSERT_LIBRARIES was set.
Setting (DY)LD_LIBRARY_PATH is only necessary for (standalone)
shared-library builds, so a better solution is to only set the
environment variable when necessary.
Differential revision: https://reviews.llvm.org/D67012
llvm-svn: 370549
As promised, I've updated the comment for the C4324 MSVC warning that was re-disabled at rL367409 / rG8f823e63e3edf87ab029ba32b68f3eb5d2f392b5 to put it in terms of currently supported VS versions
llvm-svn: 369368
Address post-commit comment on D66256 regarding the `else( MSVC )` block
containing only blocks guarded with `LLVM_COMPILER_IS_GCC_COMPATIBLE`,
which would imply `NOT MSVC`.
llvm-svn: 369221
Summary:
LLVM now requires C++14. For IBM XL compilers with C++14 support, this
can be done with the GCC-style options. The relevant block in the CMake
file is split up into smaller parts as part of this patch to allow the
common cases to be shared.
Reviewers: jfb, jasonliu, daltenty, xingxue
Reviewed By: jfb, xingxue
Subscribers: mstorsjo, mgorny, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66256
llvm-svn: 369058
It is sometimes useful to have the C++ standard library linked into the
assembly when compiling clang, particularly when distributing a compiler
onto systems that don't have a copy of stdlibc++ or libc++ installed.
This functionality should work with either GCC or Clang as the host
compiler, though statically linking libc++ (as may be required for
licensing purposes) is only possible if the host compiler is Clang with
a copy of libc++ available.
Differential Revision: https://reviews.llvm.org/D65603
llvm-svn: 368907
Summary:
Back in January I changed the minimum toolchain version required to build clang
and LLVM: D57264. Since then we've release LLVM 8, following
[our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain)
it's therefore now a good time to remove the soft-error and officially deprecate
older toolchains. I tried this out last Tursday night to see if any bots
complained, and I saw no complaints. I also manually audited bots and didn't see
any bot that should break, but their toolchain information is unreliable and
some bots are offline.
Once this patch stick we'll move to C++14 as we've
[already agreed](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html).
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, EricWF, thakis, chandlerc
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66188
llvm-svn: 368799
It's been in for more than 30 min and no bots have complained. Let's see if some
slow ones catch up. I'll do another manual pass on bots later (in case some that
were down are back up), and then turn this on permanently through a regular
review.
llvm-svn: 368253
It's pretty hard to find a reliable list of which bots use which compiler version... so I'm going to commit this change which allows us to mandate the compilers required for C++14. This bump is what we've already agreed to do, so I'll use the list of failures to figure out which bots need to bump their compiler version. I'll revert the change in a few minutes.
The last discussion of this is here: http://lists.llvm.org/pipermail/llvm-dev/2019-August/134360.html
llvm-svn: 368252
Append a default CMake suffix (CMAKE_EXECUTABLE_SUFFIX) for the build host to the toolchain tool path when adding a LLVM external project.
The tool binary files should contain .exe suffix to run them properly on Windows platform when building the projects.
Patch by Vlad Vereschaka.
Differential Revision: https://reviews.llvm.org/D65824
llvm-svn: 368121
Summary: If you are generating an object library that depends on table-gen generate sources, you need the object library to depend on the tablgen target. Currently llvm_add_library doesn't add dependencies for object libraries at all, which is clearly problematic.
Reviewers: compnerd, hintonda, smeenai
Reviewed By: smeenai
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65818
llvm-svn: 368074
Summary:
This patch maps in the `-qnoeh` and `-qnortti` options for building with
IBM XL compilers.
Reviewers: daltenty, xingxue, jasonliu
Reviewed By: daltenty
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65669
llvm-svn: 368050
This dependency was removed in r357486, which has lead to a stream of difficult to diagnose bugs.
Without this dependency, when building with `LLVM_OPTIMIZED_TABLEGEN=On` the native tablegen executible may not be rebuilt at all, and often won't get rebuilt before targets that use the tablegen headers. In the best case this results in a build-time failure, in the worst case it results in runtime failures.
llvm-svn: 367895
Summary: The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, according to the comment above, isn't relevant anymore.
Reviewers: rnk
Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65458
llvm-svn: 367383
This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure
that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on
Solaris succeed by always making the host and freshly built clang consistent.
Tested on x86_64-pc-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64483
llvm-svn: 367304
Like other ELF targets, shared objects should be linked with -z defs on Solaris.
Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11.
Differential Revision: https://reviews.llvm.org/D64484
llvm-svn: 366821
There were two main problems:
* The 'nativecodegen' pseudo-component was unconditionally adding
${native_tgt}CodeGen even though it conditionally added ${native_tgt}Info and
${native_tgt}Desc. This has been fixed by making ${native_tgt}CodeGen
conditional too
* The 'all' pseudo-component was causing library names like LLVMLLVMDemangle as
the expansion was to a library name and not a component. There doesn't seem to
be a list of available components anywhere so this has been fixed by moving the
expansion of 'all' back where it was before. This manifested in different ways
on different builders but it was the same root cause
llvm-svn: 366622
Some targets are missing LLVMDemangle, one is adding the LLVM prefix twice, and two
are hitting the very error this patch fixes for my target. Reverting while I work
through the reports.
llvm-svn: 366615
I believe this to have been a latent bug as the same expansion checks for the
existence of ${native_tgt}Info and ${native_tgt}Desc and only adds them if
they were compiled but unconditionally adds ${native_tgt}CodeGen.
This should fix llvm-clang-x86_64-win-fast which builds ARM only on an X86 host and similar builders.
llvm-svn: 366612
Summary:
If you use pseudo-targets like AllTargetsCodeGens in LLVM_DYLIB_COMPONENTS
then a test will fail because `./bin/llvm-config --shared-mode` can't
handle these targets. We can fix this by expanding them before embedding
the string into llvm-config
Reviewers: bogner
Reviewed By: bogner
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65011
llvm-svn: 366610
lldb recently added a tablegen tool. In order to properly cross compile
lldb standalone there needs to be a mechanism to generate the native
lldb build, analgous to what's done for the NATIVE llvm build. Thus,
we can simply modify this setup to allow for any project to be used.
llvm-svn: 366514
Summary:
Other platforms don't have the capability to perform llvm_codesign
step. If LLVM_CODESIGNING_IDENTITY is set then this chunk of code would
attempt to codesign if the target was Apple. But when cross compiling
to Darwin from Linux, for example, this step would fail. So test if the
host is Apple as well.
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64942
llvm-svn: 366498
Summary:
This is a follow up to D64032. Afterwards if building utils is disabled
and cross compilation is attempted, CMake will complain that adding
`install()` directives to targets with EXCLUDE_FROM_ALL set is "undefined".
Indeed, it appears depending on the CMake version and the selected
Generator, the install rule will error because the underlying target isn't
built. Fix that by not adding the install rule if building utils is not
requested. Note that this doesn't prevent building tblgen as a
dependency in not cross-build, even if building tools is disabled.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D64225
llvm-svn: 366108
Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
Reviewers: beanz, smeenai
Reviewed By: beanz
Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64580
llvm-svn: 365902
Summary:
CMake+Xcode doesn't seem to handle targets that only have object
sources. This patch works around that limitation by adding a dummy
soruce file to any library target that is generated by llvm_add_library
when object libraries are generated.
Object libraries are generated whenever llvm_add_library is passed more
than one library type, which is now the default case for clang static
libraries (which generate STATIC and OBJECT libraries).
Reviewers: zturner, compnerd, joanlluch
Reviewed By: joanlluch
Subscribers: joanlluch, xbolva00, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64300
llvm-svn: 365365
Summary:
In cross mode, we build a separate NATIVE tblgen that runs on the
host and is used during the build. Separately, we have a flag that
disables building all executables in utils/. Of course generally,
this doesn't turn off tblgen, since we need that during the build.
In cross mode, however, that tblegen is useless since we never
actually use it. Furthermore, it can be actively problematic if the
cross toolchain doesn't like building executables for whatever reason.
And even if building executables works fine, we can at least save
compile time by omitting it from the target build. There's two changes
needed to make this happen:
- Stop creating a dependency from the native tool to the target tool.
No such dependency is required for a correct build, so I'm not entirely
sure why it was there in the first place.
- If utils were disabled on the CMake command line and we're in cross mode,
respect that by excluding it from the install target (using EXCLUDE_FROM_ALL).
Reviewers: smeenai
Differential Revision: https://reviews.llvm.org/D64032
llvm-svn: 364872
Summary:
With r363420, config.guess can no longer be run with MSYS on Windows and this
patch should be able to fix this particular case.
Reviewers: compnerd
Reviewed By: compnerd
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63834
llvm-svn: 364485
This is a follow up to D56781, D56774 and D35077 to makes the LLVM-C.dll
file and LLVM-C.lib be installed on Windows, just like LTO.dll and
LTO.lib are.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D63717
llvm-svn: 364275
Summary:
Specify message levels in CMake. Prefer STATUS (stdout).
As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools, noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step.
This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR) instead of the default.
* I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations.
* Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know.
Patch by: Christoph Siedentop
Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz
Reviewed By: sgraenitz
Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits
Tags: #sanitizers, #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D63370
llvm-svn: 363821
This extracts the LLVM distribution target handling into a support module.
Extraction will enable us to restructure the builds to support multiple
distribution configurations (e.g. developer and user) to permit us to build the
development package and the user package at once.
llvm-svn: 363440
When cross-compiling LLVM to android from Windows (for LLVMSupport), we would
attempt to execute `config.guess` to determine the host triple since
`CMAKE_SYSTEM_NAME` is not Windows and `CMAKE_C_COMPILER` will be set to GNU or
Clang. This will fail as `config.guess` is a shell script which cannot be
executed on Windows. Simply log a warning instead. The user can specify the
value for this instead in those cases.
llvm-svn: 363420
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.
This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.
We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.
Reviewers: hubert.reinterpretcast, xingxue, andusy
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, jsji, cfe-commits, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D62533
llvm-svn: 362808
Summary: Useful info for standalone builds of subprojects. If a multi-configuration generator was used for the provided LLVM build-tree, standalone builds should consider actual subdirectories per configuration in `find_program()` (e.g. looking for `llvm-lit` or `llvm-tblgen`).
Reviewers: labath, beanz, mgorny
Subscribers: lldb-commits, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62878
llvm-svn: 362588
Add `nm` and `objcopy` to the default value for the tools that we install now
that they are sufficiently feature complete to replace bintuils' implementation.
Patch by Jiang Yi!
llvm-svn: 362425
Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage.
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
```
$ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
check-clang-analysis
check-clang-analysis-checkers
check-clang-analysis-copypaste
check-clang-analysis-diagnostics
check-clang-analysis-engine
check-clang-analysis-exploration_order
check-clang-analysis-html_diagnostics
check-clang-analysis-html_diagnostics-relevant_lines
check-clang-analysis-inlining
check-clang-analysis-objc
check-clang-analysis-unified-sources
check-clang-analysis-z3
```
3) Simplify the logic and only include the subdirectories under
clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.
Reviewed By: NoQ
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62445
llvm-svn: 362328
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.
Differential Revision: https://reviews.llvm.org/D62769
llvm-svn: 362313
This feeds the new llvm_codsign BUNDLE_PATH option through from the llvm target wrapper functions, so that you can specify the BUNDLE_PATH on the target's codesign.
llvm-svn: 362248
CMake always uses absolute file paths in the generated compiler
invocation which results in absolute file paths being embedded in debug
info. This is undesirable when building a toolchain e.g. on bots as the
debug info may embed the bot source checkout path which is meaningless
anywhere else.
This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses
-fdebug-prefix-map (where supported) options to rewrite paths embedded
into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can
be used to override the path to source directory with a different one.
Differential Revision: https://reviews.llvm.org/D62622
llvm-svn: 362185
Summary:
Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This results in an invalid bundle code signature because the signature only applies to the binaries not the resources.
This patch adds two new options to `llvm_codesign` to enable re-signing the library and XPC service as bundles.
The `BUNDLE_PATH` option allow specifying an explicit path to codesign, which enables signing bundles which aren't generated using CMake's `FRAMEWORK` or `BUNDLE` target properties.
The `FORCE` option allows re-signing binaries that have already been signed. This is required for how clangd exposes the clangd library and tools as both XPC and non-XPC services using the same binary.
Reviewers: jkorous, bogner
Reviewed By: bogner
Subscribers: mgorny, ilya-biryukov, dexonsmith, arphaman, kadircet, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62693
llvm-svn: 362169
This reverts r361790 (git commit fe5eaab2b5b4523886bd63aebcfea8cfce586fa1)
It's causing buildbot breakage, so reverting while I investigate.
llvm-svn: 361793
Summary:
The following changes were required to fix these tests:
1) Change LLVM_ENABLE_PLUGINS to an option and move it to
llvm/CMakeLists.txt with an appropriate default -- which matches
the original default behavior.
2) Move the plugins directory from clang/test/Analysis
clang/lib/Analysis. It's not enough to add an exclude to the
lit.local.cfg file because add_lit_testsuites recurses the tree and
automatically adds the appropriate `check-` targets, which don't
make sense for the plugins because they aren't tests and don't
have `RUN` statements.
Here's a list of the `clang-check-anlysis*` targets with this
change:
```
$ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
check-clang-analysis
check-clang-analysis-checkers
check-clang-analysis-copypaste
check-clang-analysis-diagnostics
check-clang-analysis-engine
check-clang-analysis-exploration_order
check-clang-analysis-html_diagnostics
check-clang-analysis-html_diagnostics-relevant_lines
check-clang-analysis-inlining
check-clang-analysis-objc
check-clang-analysis-unified-sources
check-clang-analysis-z3
```
3) Simplify the logic and only include the subdirectories under
clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.
Reviewed By: NoQ
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62445
llvm-svn: 361790
This reverts commit r361340. The following builder has been broken for
the past few days because of this commit:
http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/
Also revert r361399, which was committed to fix r361340.
llvm-svn: 361685
Summary:
For the most part this consists of replacing ${LLVM_TARGETS_TO_BUILD} with
some combination of AllTargets* so that they depend on specific components
of a target backend rather than all of it. The overall effect of this is
that, for example, tools like opt no longer falsely depend on the
disassembler, while tools like llvm-ar no longer depend on the code
generator.
There's a couple quirks to point out here:
* AllTargetsCodeGens is a bit more prevalent than expected. Tools like dsymutil
seem to need it which I was surprised by.
* llvm-xray linked to all the backends but doesn't seem to need any of them.
It builds and passes the tests so that seems to be correct.
* I left gold out as it's not built when binutils is not available so I'm
unable to test it
Reviewers: bogner, JDevlieghere
Reviewed By: bogner
Subscribers: mehdi_amini, mgorny, steven_wu, dexonsmith, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62331
llvm-svn: 361567
which doesn't play well with passing CMAKE_MAKE_PROGRAM from the
commandline without a path.
Fixes a bug introduced in r361280.
Thanks to Mikael Holmén for reporting this!
llvm-svn: 361501
These are needed to avoid undefined symbols which aren't satisfied
by Clang itself.
Differential Revision: https://reviews.llvm.org/D62174
llvm-svn: 361340
Summary:
clang and newer versions of ninja use high-resolutions timestamps, but
older versions of libtool on Darwin don't, so the archive will often
get an older timestamp than the last object that was added or updated.
To fix this, we add a custom command to touch the archive after it's
been built so that ninja won't rebuild it unnecessarily the next time
it's run.
Reviewed By: beanz
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62172
llvm-svn: 361280
