Commit Graph

1615 Commits

Author SHA1 Message Date
Balazs Benics 45ab67721e [NFC] Fix Z3 version detection regexp
Summary:
We use the `major.minor.build` version format in this file, except when we try
to parse the result of the test binary.
In that regular expression, we expect the `major.minor.build.rev` format, which
is never fulfilled.

Reviewers: NoQ, george.karpenkov, alexandre.isoard, serge-sans-paille

Reviewed By: NoQ

Subscribers: mgorny, mikhail.ramalho, Charusso, martong, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76837
2020-04-09 13:06:22 +02:00
Nico Weber d4638cbad7 Make paths in generated llvm-lit relative as well.
This builds on top of D77184. With this, I can rename my build directory
to a different name and `bin/llvm-lit ../llvm-project/clang/test
../llvm-project/llvm/test` still succeeds.

I haven't tried copying the build dir to a different machine to run
tests there yet, but I tried something like it a few months ago and it
worked back then.

Changes:
- Make configure_lit_site_cfg() store the main / generated config pair
  interleaved in the LLVM_LIT_CONFIG_FILES list and postpone converting
  it to python code to llvm-lit's CMakeList.
- Pull the relpath code into a new function make_paths_relative() and
  call that in llvm-lit's CMakeList, prior to converting the list to
  python code.
- Pull the path() function into a variable and use that in llvm-lit's
  CMakeList too.

Differential Revision: https://reviews.llvm.org/D77496
2020-04-06 09:18:23 -04:00
Nico Weber 7db64e202f Disable relative paths in lit.site.cfg in presence of symlinks
See https://reviews.llvm.org/D77184#1961208
2020-04-04 12:35:40 -04:00
Nico Weber 18a18b2001 Fix standalone clang builds after fb80b6b2d5.
When clang is built against a prebuilt LLVM, LLVM_SOURCE_DIR is
empty, which due to a cmake quirk caused list lengths to get out
of sync. Add a workaround.
2020-04-03 17:15:09 -04:00
Andrew Ng dbb0d8ecb3 Don't use relpaths in lit cfg if build/source dir are on different drives.
See discussion on https://reviews.llvm.org/D77184.
2020-04-03 15:43:50 -04:00
Stephen Neuendorffer 0c0831f74b [CMAKE] Plumb include_directories() into tablegen()
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths.  This
becomes unwieldy as there are more users for which these paths are
insufficient.  For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen.  As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().

I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful.  There are several users in clang which apparently
don't have the current directory as an include_directories().  This could
be considered separately.

The new version of this path uses list APPEND rather than list TRANSFORM,
in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then
we can use list TRANSFORM instead.

Differential Revision: https://reviews.llvm.org/D77156
2020-04-03 11:23:38 -07:00
Stephen Neuendorffer f288c21687 Revert "[CMAKE] Plumb include_directories() into tablegen()"
This reverts commit ae044c5b0c.

This breaks the buildbots, which use an older version of cmake.
2020-04-03 10:47:36 -07:00
Stephen Neuendorffer ae044c5b0c [CMAKE] Plumb include_directories() into tablegen()
Previously, the tablegen() cmake command, which defines custom
commands for running tablegen, included several hardcoded paths.  This
becomes unwieldy as there are more users for which these paths are
insufficient.  For most targets, cmake uses include_directories() and
the INCLUDE_DIRECTORIES directory property to specify include paths.
This change picks up the INCLUDE_DIRECTORIES property and adds it
to the include path used when running tablegen.  As a side effect, this
allows us to remove several hard coded paths to tablegen that are redundant
with specified include_directories().

I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which
seems generically useful.  There are several users in clang which apparently
don't have the current directory as an include_directories().  This could
be considered separately.

Differential Revision: https://reviews.llvm.org/D77156
2020-04-03 10:38:25 -07:00
Nico Weber 20cb7a904f This might actually fix the Windows bots after a16ba6fea. 2020-04-02 22:22:54 -04:00
Nico Weber c7aff9a109 another wild guess at the win bot-only failures 2020-04-02 21:23:05 -04:00
Nico Weber 8838d6d356 try more to appease win bots 2020-04-02 20:27:31 -04:00
Nico Weber e875ba1509 Try again to get tests passing again on Windows.
Things pass locally, but some tests on some bots are still unhappy.
I'm not sure why. See if using forward slashes as before helps.
2020-04-02 20:00:38 -04:00
Nico Weber a16ba6fea2 Reland "Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang"
The problem on Windows was that the \b in "..\bin" was interpreted
as an escape sequence. Use r"" strings to prevent that.

This reverts commit ab11b9eefa,
with raw strings in the lit.site.cfg.py.in files.

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 16:12:03 -04:00
Nico Weber ab11b9eefa Revert "Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang"
This reverts commit fb80b6b2d5 and
follow-up 631ee8b24a.

Seems to not work on Windows:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/31684
http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/6512

Let's revert while I investigate.
2020-04-02 15:00:09 -04:00
Nico Weber 631ee8b24a Make fb80b6b2d5 actually work.
I broke it with last-minute changes right before committing.

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 14:28:34 -04:00
Nico Weber fb80b6b2d5 Make it possible for lit.site.cfg to contain relative paths, and use it for llvm and clang
Currently, all generated lit.site.cfg files contain absolute paths.

This makes it impossible to build on one machine, and then transfer the
build output to another machine for test execution. Being able to do
this is useful for several use cases:

1. When running tests on an ARM machine, it would be possible to build
   on a fast x86 machine and then copy build artifacts over after building.

2. It allows running several test suites (clang, llvm, lld) on 3
   different machines, reducing test time from sum(each test suite time) to
   max(each test suite time).

This patch makes it possible to pass a list of variables that should be
relative in the generated lit.site.cfg.py file to
configure_lit_site_cfg(). The lit.site.cfg.py.in file needs to call
`path()` on these variables, so that the paths are converted to absolute
form at lit start time.

The testers would have to have an LLVM checkout at the same revision,
and the build dir would have to be at the same relative path as on the
builder.

This does not yet cover how to figure out which files to copy from the
builder machine to the tester machines. (One idea is to look at the
`--graphviz=test.dot` output and copy all inputs of the `check-llvm`
target.)

Differential Revision: https://reviews.llvm.org/D77184
2020-04-02 13:53:16 -04:00
Nathan Lanza 7f5fe30a15 [cmake] Only set deps for an ExternalProject if the type is executable or library
Summary:
cmake fails with an error when attempting to evaluate $<TARGET_FILE:tgt>
where `tgt` is defined via an `add_custom_target` and thus the `TYPE`
is `UTILITY`. Requesting a TARGET_FILE only works on an `EXECUTABLE`
or one of a few differetnt types of `X_LIBRARY` (e.g. added via
`add_library` or `add_executable`). The logic as implemented in cmake
is below:

  enum TargetType
  {
    EXECUTABLE,
    STATIC_LIBRARY,
    SHARED_LIBRARY,
    MODULE_LIBRARY,
    OBJECT_LIBRARY,
    UTILITY,
    GLOBAL_TARGET,
    INTERFACE_LIBRARY,
    UNKNOWN_LIBRARY
  };

  if (target->GetType() >= cmStateEnums::OBJECT_LIBRARY &&
      target->GetType() != cmStateEnums::UNKNOWN_LIBRARY) {
    ::reportError(context, content->GetOriginalExpression(),
                  "Target \"" + name +
                    "\" is not an executable or library.");
    return nullptr;
  }

This has always been the case back to at least 3.12 (furthest I
checked) but this is causing a new failure in cmake 3.17 while
evaluating ExternalProjectAdd.

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77284
2020-04-01 23:29:01 -04:00
Simon Tatham 6a946993d5 Do export symbols when LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is on.
Summary:
In D76527, we stopped exporting symbols from clang, opt and llc unless
the `LLVM_ENABLE_PLUGINS` cmake variable is true (which causes clang's
own plugin collection to be built).

But another reasonable build configuration is to ask clang to export
its symbols for out-of-tree plugins to use, without building the
in-tree ones. That is, you might set `LLVM_EXPORT_SYMBOLS_FOR_PLUGINS`
without also setting `LLVM_ENABLE_PLUGINS` (at least if you're using
MSVC, where you need to ask explicitly for the symbols to be
exported).

In that situation, the symbols should still be exported, but after
D76527, they weren't being.

Reviewers: efriedma, john.brawn

Reviewed By: efriedma, john.brawn

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76760
2020-03-26 09:07:02 +00:00
Eli Friedman 896335bfb8 Don't export symbols from clang/opt/llc if plugins are disabled.
The only reason we export symbols from these tools is to support
plugins; if we don't have plugins, exporting symbols just bloats the
executable and makes LTO less effective.

See review of D75879 for the discussion that led to this patch.

Differential Revision: https://reviews.llvm.org/D76527
2020-03-23 12:17:09 -07:00
Petr Hosek 8a8778f25f [CMake] Enable the use of -ffile-prefix-map
This handles not paths embedded in debug info, but also in sources.
Since the use of this flag is controlled by an option, rather than
replacing the new option, we add a new option.

Differential Revision: https://reviews.llvm.org/D76018
2020-03-19 15:14:15 -07:00
Cullen Rhodes 5c296df0c0 [ValueTypes] Add EVT::isFixedLengthVector
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
2020-03-19 10:08:17 +00:00
Sander de Smalen 8105935d3a [TypeSize] Allow returning scalable size in implicit conversion to uint64_t
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
2020-03-15 13:48:49 +00:00
Amy Huang 9a349d66c9 CMake: Turn LLVM_ENABLE_ZLIB into a tri-state option
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
2020-03-13 13:52:46 -07:00
Tom Stellard 87d8ae700b [clang][cmake] Include generated rst files in html built by docs-clang-html target
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
2020-03-05 21:30:37 -08:00
Hans Wennborg 916be8fd6a Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)
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.
2020-03-03 11:03:09 +01:00
Nicolai Hähnle 1d104f7549 Build fix: Turn off _GLIBCXX_DEBUG based on a compile check
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
2020-03-02 16:16:26 +01:00
Petr Hosek 50a6d3a648 [CMake] Use PUBLIC link mode for static libraries
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
2020-02-29 11:05:59 -08:00
Michael Liao 1a52d3d47b [cmake] Fix LLVM_USE_SPLIT_DWARF
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
2020-02-28 23:05:55 -05:00
Simon Pilgrim d76fddf2f1 [cmake][msvc] Don't disable C4345 any more.
This shouldn't be relevant now that we just support VS2017+.
2020-02-28 13:57:20 +00:00
Hans Wennborg dcd89b3de6 Add llvm-cov to LLVM_TOOLCHAIN_TOOLS
See https://github.com/llvm/llvm-project/issues/141
2020-02-25 10:59:55 +01:00
Michael Kruse 6369b9bf31 [CMake] Default to static linking for subprojects.
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
2020-02-24 11:54:08 -06:00
David Tenty 9e0c95572e [AIX] Improve 32/64-bit build configuration
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
2020-02-20 15:41:00 -05:00
serge-sans-paille def62c7f65 [NFC] Remove ar/ranlib test noise during cmake step
At least on RHEL, ar outputs on stderr a message similar to

        .../bin/ar: creating t.a

Which creates noise during the cmake step. Get rid of it.
2020-02-20 11:26:26 +01:00
serge-sans-paille 3a0f6e699b Fix compiler extension in standalone mode
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
2020-02-20 07:19:04 +01:00
Louis Dionne 84f80b1faa [CMake] Only detect the linker once in AddLLVM.cmake
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
2020-02-19 13:53:38 -05:00
Cristian Adam d6fe253653 llvm: Use quotes around MSVC_DIA_SDK_DIR CMake variable
MSVC_DIA_SDK_DIR variable will point to a path which contains spaces,
and without quotes it will fail to configure the project.
2020-02-18 14:42:19 +02:00
Gokturk Yuksek cef85193b2 [CMake] CheckAtomic.cmake: catch false positives in RISC-V
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
2020-02-17 18:53:41 +00:00
Luís Marques f128f442a3 [CMake] Fix setting result of libatomic check for MSVC
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.
2020-02-17 15:32:28 +00:00
serge-sans-paille 87dac7da68 Fix standalone build interaction with compiler extension
As suggested in https://github.com/llvm/llvm-project/issues/120, don't try to
generate the extension file from clang, only do the linking step.

Fixes the regression introduced in D74464 when running cmake inside the clang
directory.

Differential Revision: https://reviews.llvm.org/D74602
2020-02-15 11:10:51 +01:00
Nico Weber 09153ab9d2 [windows] Add /Gw to compiler flags
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
2020-02-14 15:15:00 -05:00
Luís Marques de1c2877a9 llvm/cmake/config.guess: add support for riscv32 and riscv64
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
2020-02-14 11:53:51 +00:00
Fangrui Song 04b4866ba4 [CMake] Delete llvm_add_go_executable and a reference to TARGET llvm-go
llvm-go was deleted by 102814b4d3.
2020-02-11 20:55:50 -08:00
Petr Hosek fdfdd275fd [CMake] Use LLVM tools external project build where possible
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
2020-02-07 13:43:30 -08:00
Jonas Devlieghere 4fe839ef3a [CMake] Rename EXCLUDE_FROM_ALL and make it an argument to add_lit_testsuite
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
2020-02-06 15:33:18 -08:00
Saleem Abdulrasool a43bf80788 build: attempt to repair the build
The change in 9b84dabc5f uses a newer
syntax which not all the builders support.  Use an explicit `OR` over
the languages instead to repair the builders.
2020-02-02 16:18:00 -08:00
Saleem Abdulrasool 9b84dabc5f build: only pass -UNDEBUG when compiling C/C++
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!
2020-02-02 13:19:23 -08:00
Mehdi Amini 5f940220bf MSVC Buggy version detection: turn pre-processor error into CMake configuration time check
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
2020-01-31 00:11:55 +00:00
Mehdi Amini 1e417ba2d4 Revert "MSVC Buggy version detection: turn pre-processor error into CMake configuration time check"
This reverts commit b4fac78246.
It broke the MSVC bot
2020-01-30 23:38:36 +00:00
Mehdi Amini b4fac78246 MSVC Buggy version detection: turn pre-processor error into CMake configuration time check
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
2020-01-30 22:17:21 +00:00
Petr Hosek 56b7f595d2 [CMake] Set ASM compiler for external projects
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
2020-01-28 11:39:21 -08:00