This reverts commit 2aca33ba.
Broke tests on several bots, see comments on https://reviews.llvm.org/D120305

This option controls whether -opaque-pointers or -no-opaque-pointers
is the default. Once opaque pointers are enabled by default, this
will provide a simple way to temporarily opt-out of the change.

Differential Revision: https://reviews.llvm.org/D123122

(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.

Differential Revision: https://reviews.llvm.org/D120305

When lld is being used as host linker, skip version detection since
lld version cannot be used interchangeably with ld64 version and lld
is already handled specially in Clang driver.

Differential Revision: https://reviews.llvm.org/D122109

See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.

This reverts commit 3c4ed026
and some followup changes.

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX will be removed in the future.

Reviewed By: thesamesam

Differential Revision: https://reviews.llvm.org/D120305

The clang-analyzer plugins are not linked to a particular tool, so they
can only be compiled if plugins are broadly supported. We could opt
instead to decide whether to link them to specifically against clang or
with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS,
but we do not currently expect there to be a use case for that rather
niche configuration.

Differential Revision: https://reviews.llvm.org/D119591

Ensure CLANG_PLUGIN_SUPPORT is compatible with llvm_add_library.
Fixes an issue noted in D111100.

Differential Revision: https://reviews.llvm.org/D119199

- If not using `llvm-config`, `LLVM_MAIN_SRC_DIR` now has a sane default

- `LLVM_CONFIG_PATH` will continue to work for LLD for back compat.

- More quoting of paths in an abundance of caution.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D118792

This method introduces new CMake variable
PPC_LINUX_DEFAULT_IEEELONGDOUBLE (false by default) to enable fp128 as
default long double format.

Reviewed By: jsji

Differential Revision: https://reviews.llvm.org/D118110

I am breaking apart D99484 so the cause of build failures is easier to
understand.

Differential Revision: https://reviews.llvm.org/D117419

https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have
this odd error, not sure how to reproduce, so I will just try breaking
up my patch.

This reverts commit 4a678f80.

This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!

It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up

 - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.

 - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.

These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.

Reviewed By: #libunwind, #libc, #libc_abi, compnerd

Differential Revision: https://reviews.llvm.org/D99484

Sorry for the disruption, I will try again later.

This reverts commit efeb5019.

This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!

It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up

 - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.

 - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.

These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.

Reviewed By: #libunwind, #libc, #libc_abi, compnerd

Differential Revision: https://reviews.llvm.org/D99484

See the docs in the new function for details.

 I think I found every instance of this copy pasted code. Polly could
 also use it, but currently does something different, so I will save the
 behavior change for a future revision.

We get the shared, non-installed CMake modules following the pattern
established in D116472.

It might be good to have LLD and Flang also use this, but that would be
a functional change and so I leave it as future work.

Reviewed By: beanz, lebedev.ri

Differential Revision: https://reviews.llvm.org/D116521

In that revision, I make LLD match Clang in deprecating `llvm-config`.
This patch isn't to worthwhile on its own --- there isn't a sense in
which the new order is "better" in isolation --- but by putting the
steps that LLD also neeeds to do first, I make the diff between LLD and
Clang's top-level `CMakeLists.txt` very legible.

Longer term I hope:

 1. We can remove calling `llvm-config` altogether, and just go strait to
    finding the CMake config file. This is what Flang does, at least.

 2. Hopefully the diffable part is smaller then --- i.e. there is less
    duplicated boilerplate.

 3. Any duplicate boilerplate that remains can be factored out.

I didn't both trying to factor anything out in e.g. the top level common
CMake Utility modules because this deprecated-but-not-removed state is a
merely transitional.

Reviewed By: beanz

Differential Revision: https://reviews.llvm.org/D116548

In 2015-05, GCC added the configure option `--enable-default-pie`. When enabled,

* in the absence of -fno-pic/-fpie/-fpic (and their upper-case variants), -fPIE is the default.
* in the absence of -no-pie/-pie/-shared/-static/-static-pie, -pie is the default.

This has been adopted by all(?) major distros.

I think default PIE is the majority in the Linux world, but
--disable-default-pie users is not that uncommon because GCC upstream hasn't
switched the default yet (https://gcc.gnu.org/PR103398).

This patch add CLANG_DEFAULT_PIE_ON_LINUX which allows distros to use default PIE.
The option is justified as its adoption can be very high among Linux distros
to make Clang default match GCC, and is likely a future-new-default, at which
point we will remove CLANG_DEFAULT_PIE_ON_LINUX.
The lit feature `default-pie-on-linux` can be handy to exclude default PIE sensitive tests.

Reviewed By: foutrelis, sylvestre.ledru, thesamesam

Differential Revision: https://reviews.llvm.org/D113372

This removes the ability to disable roundtripping in assert builds.
(Roundtripping happens by default in assert builds both before and after
this patch.)

The CLANG_ROUND_TRIP_CC1_ARGS was added as an escape hatch 9 months ago
in https://reviews.llvm.org/D97462, with a FIXME to remove it eventually.
It's probably time to remove it.

Differential Revision: https://reviews.llvm.org/D114120

Reviewed By: xgupta

Differential Revision: https://reviews.llvm.org/D110836

This matches handling of other CMake variables.

Differential Revision: https://reviews.llvm.org/D110463

When building clang in stage2, when -DCMAKE_BUILD_TYPE=RelWithDebInfo is set,
the developer can expect that the stage2 clang is built using the same mode.
Especially as the performances are much worst in debug mode.
(Principle of least astonishment)

Differential Revision: https://reviews.llvm.org/D53014

This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D107717

This patch enables cc1 argument round-trip for assert builds. It can be disabled by building clang with `-DCLANG_ROUND_TRIP_CC1_ARGS=OFF`.

This will be committed only if we reach consensus in https://lists.llvm.org/pipermail/cfe-dev/2021-February/067714.html.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D97462

This code was written back when LLVM's minimum required CMake version
was 2.8.8, and I assume ExternalProject_Add_Step didn't take this option
at that point. It does now though, so we should just use the option.
Setting the _EP_* property is entirely equivalent (and is in fact how
these commands behave internally), but that also feels like an internal
implementation detail we shouldn't be relying on.

Reviewed By: beanz

Differential Revision: https://reviews.llvm.org/D99322

We want installs to be executed even if binaries haven't changed, e.g.
so that we can install to multiple places. This is consistent with how
non-multi-stage install targets (e.g. the regular install-distribution
target) behave.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D99321

LLD does not support SystemZ, so it doesn't make sense to use it for
boostrap/stage3 builds, and using LTO in these cases won't work.

Differential Revision: https://reviews.llvm.org/D89942

Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used.

This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter.

If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions.

Differential Revision: https://reviews.llvm.org/D98278

The lit test suite uses python 3.6 features. Rather than a strange
python syntax error upon running the lit tests, we will require the
correct version in CMake.

Reviewed By: serge-sans-paille, yln

Differential Revision: https://reviews.llvm.org/D95635

002dd47b was meant to not be any
functional change, but it turned out it was.

With CLANG_DEFAULT_RTLIB set to compiler-rt, CLANG_DEFAULT_UNWINDLIB used
to bet set to an empty string, but now was set to "none".

If one only overrode rtlib to libgcc, one previously would get libgcc
as unwind lib, but now didn't. This caused test failures, fixed in
41476d89.

Secondly, for the android target, the previous default was to link
libunwind, which this now changed.

Reinstate the exact same behaviour as before (removing the previously
typoed cmake check) and fix the option comment in one place to match
the other one above.

Differential Revision: https://reviews.llvm.org/D98142

CLANG_DEFAULT_RTLIB had a typo, and libunwind isn't a valid
option for it.

This keeps the actual behaviour from before, defaulting to none if
using compiler-rt as rtlib.

Differential Revision: https://reviews.llvm.org/D98022

This patch implements generation of remaining header search arguments.
It's done manually in C++ as opposed to TableGen, because we need the flexibility and don't anticipate reuse.

This patch also tests the generation of header search options via a round-trip. This way, the code gets exercised whenever Clang is built and tested in asserts mode. All `check-clang` tests pass.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D94472

There are builders that do not have python 3.6. Revert until this situation can be rectified

This reverts commit 0703b075.

Previously, CMake would find any version of Python3. However, the project
claims to require 3.6 or greater, and 3.6 features are being used.

Reviewed By: yln

Differential Revision: https://reviews.llvm.org/D95635

cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.

Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D94374

Differential Revision: https://www.youtube.com/watch?v=RsL0cipURA0

This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.

Rename it internally to LLVM_ENABLE_NEW_PASS_MANAGER.

The #define for it is now in llvm-config.h.

The initial land accidentally set the value of
LLVM_ENABLE_NEW_PASS_MANAGER to the string
ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER instead of its value.

Reviewed By: rnk, hans

Differential Revision: https://reviews.llvm.org/D92072

The new pass manager was accidentally enabled by default with this change.

This reverts commit a36bd4c9.

This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.

The #define for it is now in llvm-config.h.

Reviewed By: rnk, hans

Differential Revision: https://reviews.llvm.org/D92072