Document and Enforce new Host Compiler Policy

[erichkeane]

Summary

As proposed here:
http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html

This patch enforces the 3/1.5 year error/warning policy for
the host compiler, as well as documents it in the getting
started guide.

Note that most of the patch is cribbed from (thanks JF!):
https://reviews.llvm.org/D46723

[Hahnfeld]

I don't think this change actually compiles, did it work for you?

cmake/modules/CheckCompilerVersion.cmake

10–11

This looks strange.

34

I think this has to be else if without a space!

[lebedev.ri]

cmake/modules/CheckCompilerVersion.cmake

10

This clearly should be prefixed with #

[kparzysz]

docs/GettingStarted.rst

302–304

This should refer to gcc 5.1.0.

[erichkeane]

cmake/modules/CheckCompilerVersion.cmake

10

Woops, all of this was supposed to have been deleted. Looks like my 'svn diff' didn't write properly to disk? Sorry about that.

[erichkeane]

docs/GettingStarted.rst

302–304

That is a really good catch... I found this gist that seems good enough: https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91

What do you think?

[kparzysz]

docs/GettingStarted.rst

302–304

Looks good to me. Please make sure to change the "_ask ubuntu stack exchange" one line above too if you change the link.

[probinson]

cmake/modules/CheckCompilerVersion.cmake

32

Is it possible to define meaningful variable names for all the various version numbers, and set them all at the top near the commentary describing the policy? I know these lines aren't all *that* far away, but it just seems like good engineering practice. Especially as the intent is to update these possibly as often as twice a year from now on.

[erichkeane]

Did @kparzysz 's suggestion to update the documentation (note, I changed it a bit), and @probinson 's suggestion to move the version numbers to variables.

[jfb]

Thanks for starting the discussion, the general approach seems good. I think we can discuss MSVC versions as well as STL requirements separately, along with the libstdc++ ABI problems. and whether we should statically / dynamically link libc++ in some cases.

Assuming we reach consensus on particular minimum requirement / warning period, this lgtm.

[dberris]

cmake/modules/CheckCompilerVersion.cmake

34

Suggestion on the warning, to be more direct, maybe something like:

GCC ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported (version < GCC ${GCC_WARN}).

[erichkeane]

cmake/modules/CheckCompilerVersion.cmake

34

Nice, thanks for a better wording!

[emaste]

cmake/modules/CheckCompilerVersion.cmake

7

It's not clear to me what this 7.0 statement means.

[erichkeane]

cmake/modules/CheckCompilerVersion.cmake

7

It is supposed to be our 7.0 branch. I can clarify that, thanks for hte feedback!

[erichkeane]

So, how about it? Just compiler versions for now, but hopefully this will give us the ability to use better standards versions.

[chandlerc]

I like the idea of having CMake warn users about older host toolchains that are at risk of ceasing to be supported. I might target the warning point at 2 years rather than 1.5 years though.

I don't think we're ready to go to GCC 5 yet (based on the -dev list discussion). We could go to 4.9 based on my memory of that discussion w/o folks having lots of issues, but it isn't clear how valuable that would be. But moreover, I would suggest trying to get this change in independently of actually changing the values for any of the minimum tools. This patch should establish process guidelines and helpful warnings. We can have a separate patch to actually move the bar if/when there is clear consensus around that. I've suggested adjusting the specific process description you've given below based on my personal feelings about what a good process would be.

On an unrelated note, and making the comment here rather than elsewhere to delay reigniting that email thread, I do think that for the GCC 4.9 -> GCC 5 switch, we should advertise this really clearly and loudly. Release notes, etc., around when we plan to flip the switch so that our users actually have time to get ready. For example, switching after LLVM 8 branches would be about right for us, but maybe not for other users. We should figure out this timeframe and broadcast it pretty clearly.

-Chandler

docs/GettingStarted.rst

235–239

As mentioned on the -dev thread, I don't think this is (quite) the correct policy.

I think these kind of time frames are good *guidance* that we should use when considering what the minimum toolchains supported should be. But I think other factors should also be considered. Some relevant examples from the discussion:

1. I think we should be willing to require a newer toolchain when it provides *substantial* value to LLVM, and LLVM's users won't be really negatively impacted by the requirement. For example, we might want to skip forward a bit over a release with some known big issue impacting usage of a high-value language feature. I could imagine this becoming true for C++ modules for example, although we're a long way away.

2. I think we should be willing to support older toolchains when LLVM's users would be seriously harmed by dropping support. Of course I'm a bit biased here, but both Google and several other users of LLVM are still stuck needing GCC 4.9 to be a viable host toolchain. As LLVM is first and foremost a collection of libraries, I think we have to hold ourselves to a somewhat higher bar of supporting older host toolchains. Chromium for example can always ship users a prebuilt binary, but LLVM isn't in the same boat.

3. (more minor point) I don't think we should raise the minimum versions of toolchains *just* because #2 didn't apply and it is more than three years old. Changes to minimum supported versions aren't free for users (even if they are reasonably easy to handle) and we shouldn't churn without cause.

The result is that I think we need to consider bumping up on a case-by-case basis when there is a motivation, and then check to see that any concerns can be addressed.

I'm still very happy to have temporal guidance about what our ideal state is to help direct these discussions away from pointless ones and toward where we *want* to be, even if we adjust from there for practical reasons.

[erichkeane]

In D47073#1155018, @chandlerc wrote:

I like the idea of having CMake warn users about older host toolchains that are at risk of ceasing to be supported. I might target the warning point at 2 years rather than 1.5 years though.

1.5 is derived from the '3 year' limit here. We were intending to make sure that this would warn for users for at least 'a version or two'. 2 years would likely still work since we'd have a release between the 2 and 3 years. THAT SAID, I'd be very much against a warning without some sort of date-based rule in place. Otherwise all we end up doing is making it so that changing our required compiler version become a 2 year+ long process, since we'd need to warn for that long.

I don't think we're ready to go to GCC 5 yet (based on the -dev list discussion). We could go to 4.9 based on my memory of that discussion w/o folks having lots of issues, but it isn't clear how valuable that would be. But moreover, I would suggest trying to get this change in independently of actually changing the values for any of the minimum tools. This patch should establish process guidelines and helpful warnings. We can have a separate patch to actually move the bar if/when there is clear consensus around that. I've suggested adjusting the specific process description you've given below based on my personal feelings about what a good process would be.

Issuing a warning as this patch proposes would require some sort of policy as to EOL'ing support. I'm not sure what value it has without that, since it just means upgrading compilers becomes a long and nasty process.

On an unrelated note, and making the comment here rather than elsewhere to delay reigniting that email thread, I do think that for the GCC 4.9 -> GCC 5 switch, we should advertise this really clearly and loudly. Release notes, etc., around when we plan to flip the switch so that our users actually have time to get ready. For example, switching after LLVM 8 branches would be about right for us, but maybe not for other users. We should figure out this timeframe and broadcast it pretty clearly.

I don't disagree here, clear advertising is a good idea. I don't mind rebasing this patch on 8 (as I believe you (the 'royal' you) were the only real dissent at the time to the GCC 4.8->5 switch on llvm-dev, though admittedly that doesn't terribly mean anything.

docs/GettingStarted.rst

235–239

I'm not sure I saw it so nicely laid out in the -dev thread, so I appreciate you further elaborating (or reelaborating as the case may be).

I would think that #1 and #2 are pretty contrary to each other so they would requires a pretty fine balance. In this case, there is a recurring interest for a large number of C++14/17 features (which many would argue are substantially valuable) which has precipitated this discussion every 6 months.

I definitely understand wanting to support older versions, though I have concern that it often stands in the way of progress. I presume you and I agree in concept if not in magnitude.

For #3, the purpose of this was to provide a so-called 'line in the sand' to stop #2 from allowing us to ever update the compiler. Since #2 is always going to be the status-quo, it seems to me that it'll never change without some sort of massive intervention. I guess I'd like to prevent us from being stagnated.

[jfb]

Related to this patch, don't forget to attend the BoF at the upcoming LLVM dev meeting: https://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3 🎉

[probinson]

Following up from the BoF and the corresponding email thread:
I think we want to distinguish the general guideline/intent (support N years/releases) from the firm statement "we are actually going to require *this* minimum version starting on *this* date." There seems to be some resistance to having the latter happen on a strict timeline.
Having separated out those two things, we should specify a minimum lead time for the firm statement to go from a warning to an error. I threw out 3 months as a starting point for discussion; I don't think it can reasonably be any less than that. Upgrades like this need to be tested, deployed to lots of people and bots, issues found and corrected. These things take time.

[erichkeane]

@jfb encouraged me to ping this, whats the current status/thoughts on this?

[jfb]

At the dev meeting we talked about moving past C++11 around March 2019, with the caveat that we might slip a bit if major contributors felt it was too onerous for them (they're committed to do this move, but it might take a bit more time). Some people want to move to C++14, other to C++17. It's unclear whether we'll move the language only, or the library as well. What's clear is that the build should incentivize people to move away from compilers that barely support C++11, because we're moving away soon. The versions you suggest are conservatively correct, and warning folks *now* seems desirable.

I think this is the right path forward, and we'll want to clarify things as March approaches.

[erichkeane]

Bumping again!

[jfb]

I think we want to start warning developers before the LLVM 8 branch point on January 16th. I'm assuming @hans will want to chime in.

[kristina]

I could see it making bootstrapping LLVM a lot harder (plus "golden" versions of compilers tend to be older than three years). I like the spirit of this policy, but the timeframe is pretty narrow, does GCC currently have a "golden" version? I think we should at least make sure "golden" compilers are supported for bootstrap.

[chandlerc]

I'm personally very happy for some version of this to go in, but I think the patch itself needs to be updated first? Marked bits inline.

cmake/modules/CheckCompilerVersion.cmake

10

Seems this still needs to be updated?

34

Use this in both the fatal and non-fatal versions?

docs/GettingStarted.rst

235–239

This also still needs some update?

[erichkeane]

cmake/modules/CheckCompilerVersion.cmake

10

The # refers to a previous version of the review where I'd screwed up a merge from svn. The # has been done. That said, I DO need to update this to say JUST

34

I'll reword fatal to be similar to this.

docs/GettingStarted.rst

235–239

I'd not updated this since I was expecting feedback here. I personally think that actually removing support for older compilers is necessary, however if we want the '3 year warning' in effect (GCC5.1, Clang 3.6) for 8.0, I'll refactor this to be the warning only for now (and revert the error messages to 4.8/3.1).

Guidance would be appreciated.

[erichkeane]

Reworded a thing. Still needs direction feedback for 8.0.

[jfb]

docs/GettingStarted.rst

235–239

I think for the LLVM 8 release it makes sense to have a hard error for compilers older than 3 years old, with a cmake flag to force-override. That means the error can't just be ignored, but we're being sensible because LLVM 8 doesn't technically need a newer compiler.

That way:

• A developer with a compiler older than 3 years old who compiles LLVM 8 will get an error. They'll either update their compiler, or use the cmake flag.
• A developer with a compiler older than 1.5 years just gets a warning.
• After LLVM 8, we'll hopefully be able to upgrade the C++ version LLVM uses, and the error would now become a hard error because those older compilers are actually unsupported.

[erichkeane]

Change language to make this a 'guideline' instead of a hardline policy.

Also, add an option to disable the checking.

[jfb]

CMakeLists.txt

28

"HOST_COMPILER" instead of "HOST".

cmake/modules/CheckCompilerVersion.cmake

5

This is still pretty dogmatic:

For GCC and Clang, LLVM's guideline is to support all
major compiler versions released within 3 years from the date in which the
previous version was branched. Additionally, a CMake warning is issued for
versions older than 1.5 years.

I'd say:

For GCC and Clang, LLVM's rough guideline is to support major compiler versions released about 3 years from the date in which the previous versions was branched. This time-based guideline isn't strict: we want to keep some discretion when supporting older compilers still makes sense, or when newer compilers inflict significant pain.
Additionally, a CMake warning is issued for versions older than roughly 1.5 years.

6

I'd move this to the error message, not the comment.

32

Move the instructions on silencing this error here.

63

Ditto.

docs/CMake.rst

578

Also say: this flag will be removed for LLVM 9, since we'll likely bump the required C++ version.

[jfb]

You'll also need to treat AppleClang different from Clang, since version numbering is different.

A good list of versions is: https://en.wikipedia.org/wiki/Xcode#Latest_versions
3 years puts you at AppleClang 7.3.0, and 1.5 years at 8.1.0.

cmake/modules/CheckCompilerVersion.cmake

35

The name of the macro is horrible wrong here. I like misdirection ;)

67

Ditto

docs/CMake.rst

576

Update name.

docs/GettingStarted.rst

239

I think you want to update this text as in the comment you just updated.

[erichkeane]

Few more fixes suggested by @jfb . Also, added AppleClang to the check.

[jfb]

cmake/modules/CheckCompilerVersion.cmake

35

Macro name is still wrong :)

67

Wrong here too.

100

Probably better to have this next to the clang code, so they don't diverge.

106

Name wrong.

[erichkeane]

Fixing my awful inattention to spelling in a few places, moving the AppleClang code to be more clear for future updates.

[mehdi_amini]

docs/GettingStarted.rst

239

I'm in strong agreement with Chandler here. I am not against the warning, that's probably harmless, I can even go with the "rough guideline of 3 years", even though I don't see much benefit to it since it won't affect the process much.

However I'd like to see language inserted here to mention what Chandler described (the three points) about the process for dropping any toolchain from our supported list. I would also add that the process should include an RFC thread on the LLVM-dev and CFE-dev mailing lists.

[erichkeane]

Added Policy guidance for the change process to CheckCompilerVersion.cmake.

[lebedev.ri]

Looks good, that is more in line with what i have been suggesting in IRC.
Some nits:

docs/CodingStandards.rst

187

Should this point to gcc-5.2, since that is the required version as per the check?
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/libstdc++/manual/manual/status.html#status.iso.2011

docs/GettingStarted.rst

173

Should this be 5.2?

306–322

Should all this point to 5.2, since that is the required version as per cmake check?

[erichkeane]

Fixed @lebedev.ri s comments.

[jfb]

Update is still LGTM.

[mehdi_amini]

I'd like to see docs/GettingStarted.rst updated to include some language from what Chandler mentioned. In particular upgrading a toolchain has to be *motivated* by explicit benefits, and the toolchains dropped must be evaluated with respect to the general availability for the users.

[mehdi_amini]

cmake/modules/CheckCompilerVersion.cmake

24

Has the choice of these versions be motivated in a thread on the mailing list? I.e. why go from clang 3.1 to clang 3.6 and not clang 3.5 or 3.7 for example?

[zturner]

In D47073#1354779, @mehdi_amini wrote:

I'd like to see docs/GettingStarted.rst updated to include some language from what Chandler mentioned. In particular upgrading a toolchain has to be *motivated* by explicit benefits, and the toolchains dropped must be evaluated with respect to the general availability for the users.

I think this is implied by "This time-based guideline is not strict; we want to keep some discretion when supporting older compilers still makes sense, or when newer compilers inflict significant pain."

The first part of your comment "motivated by explicit benefits" may not be implied though, so what about just adding "when supporting older compilers still make sense or is there is no significant benefit to upgrading" and leave the rest the same?

cmake/modules/CheckCompilerVersion.cmake

24

I think the idea is to accept the lowest version that supports all of the features we need.

[mehdi_amini]

In D47073#1354798, @zturner wrote:

In D47073#1354779, @mehdi_amini wrote:

I'd like to see docs/GettingStarted.rst updated to include some language from what Chandler mentioned. In particular upgrading a toolchain has to be *motivated* by explicit benefits, and the toolchains dropped must be evaluated with respect to the general availability for the users.

I think this is implied [...]

Right, I would make it more explicit:

For GCC and Clang, LLVM's guideline is to support all major compiler
versions released at least 3 years from the date in which the previous version was
branched. This time-based guideline is not strict; we will balance the benefits to
drop support for older compilers in terms of features available for development
with the availability of more recent versions on the most widely used platforms
(for example considering Ubuntu LTS, etc.).

cmake/modules/CheckCompilerVersion.cmake

24

As per the discussion about the guideline, there should be an email thread mentioning what are these features, what is the minimum version of compiler for each, and what is the availability (i.e. for example: gcc 5.2 means available by default on FreeBSD W and Ubuntu X and with PPA in Ubuntu Y. Gcc 6.3 means warning in Red Hat Z, etc.).

[hans]

In D47073#1346562, @jfb wrote:

I think we want to start warning developers before the LLVM 8 branch point on January 16th. I'm assuming @hans will want to chime in.

Apologies for being slow to reply, I was out on vacation.

I like this patch, but trying to get it in right before the release branch (which happens tomorrow) makes me a little nervous. I'd be more comfortable if it got to bake on trunk to surface any issues developers have with it, before it goes to a release branch.

Is there any particular reason why we'd need this for LLVM 8?

[jfb]

In D47073#1357505, @hans wrote:

In D47073#1346562, @jfb wrote:

I think we want to start warning developers before the LLVM 8 branch point on January 16th. I'm assuming @hans will want to chime in.

Apologies for being slow to reply, I was out on vacation.

I like this patch, but trying to get it in right before the release branch (which happens tomorrow) makes me a little nervous. I'd be more comfortable if it got to bake on trunk to surface any issues developers have with it, before it goes to a release branch.

Is there any particular reason why we'd need this for LLVM 8?

Yes: we want to warn folks early. This is just warning them, and they can opt-out. Getting it in the release branch is exactly the right place: people try out releases much more than tip-of-tree.
We want it in LLVM 8 because then there will have been enough advanced warning that, when we're ready to move away from C++11 we can do so. Tentatively, the target is end of the first quarter of 2019, so right after LLVM 8.

[mehdi_amini]

In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

[jfb]

In D47073#1358066, @mehdi_amini wrote:

In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

Yes it's a CMake error. The point is: you won't see it and will ignore it if it's just a CMake warning. What I meant was: we're giving everyone with older compilers a warning that they won't be supported soon. They can opt out and compile this once. Won't be true soon (because we'll move away from C++11). I want them to know ASAP.

[mehdi_amini]

In D47073#1358067, @jfb wrote:

In D47073#1358066, @mehdi_amini wrote:

In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

Yes it's a CMake error. The point is: you won't see it and will ignore it if it's just a CMake warning. What I meant was: we're giving everyone with older compilers a warning that they won't be supported soon. They can opt out and compile this once. Won't be true soon (because we'll move away from C++11). I want them to know ASAP.

OK but then this patch is not correct. It should not claim that the compilers aren't supported but that they are deprecated and support will be dropped in the next release.
Also the two levels (warnings vs errors) is not appropriate to accomplish what you're describing.
Finally, that still left open the choice of which compiler version the "warning" is issued.

[mehdi_amini]

One release cycle with deprecating the version we're about to remove support for using a discardable cmake error seems like a good idea in general: we should encode this in the policy as well.

[jfb]

In D47073#1358289, @mehdi_amini wrote:

In D47073#1358067, @jfb wrote:

In D47073#1358066, @mehdi_amini wrote:

In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

Yes it's a CMake error. The point is: you won't see it and will ignore it if it's just a CMake warning. What I meant was: we're giving everyone with older compilers a warning that they won't be supported soon. They can opt out and compile this once. Won't be true soon (because we'll move away from C++11). I want them to know ASAP.

OK but then this patch is not correct. It should not claim that the compilers aren't supported but that they are deprecated and support will be dropped in the next release.

Rewording along those lines sounds fine.

Also the two levels (warnings vs errors) is not appropriate to accomplish what you're describing.

I don't understand what you're asking to change here.

Finally, that still left open the choice of which compiler version the "warning" is issued.

~1.5 years, which per policy can be updated after an llvm-dev discussion.

In D47073#1358290, @mehdi_amini wrote:

One release cycle with deprecating the version we're about to remove support for using a discardable cmake error seems like a good idea in general: we should encode this in the policy as well.

Sure.

[mehdi_amini]

Also the two levels (warnings vs errors) is not appropriate to accomplish what you're describing.

I don't understand what you're asking to change here

The implementation in CMake has:

set(CLANG_MIN 3.6)
set(CLANG_WARN 4.0)

If your intent is to warn people that their host compiler won't be supported in the next release, we don't need *two* levels here.

Finally, that still left open the choice of which compiler version the "warning" is issued.

~1.5 years, which per policy can be updated after an llvm-dev discussion.

Thought it was *3* years before removing the support? (Also should be *motivated* by *benefits*)

[lhames]

In D47073#1358039, @jfb wrote:

In D47073#1357505, @hans wrote:

Is there any particular reason why we'd need this for LLVM 8?

Yes: we want to warn folks early. This is just warning them, and they can opt-out. Getting it in the release branch is exactly the right place: people try out releases much more than tip-of-tree.

Yep: It would be great to see this make it in to 8.0: I know a lot of JIT clients only check out releases.

[jfb]

In D47073#1358507, @mehdi_amini wrote:

Also the two levels (warnings vs errors) is not appropriate to accomplish what you're describing.

I don't understand what you're asking to change here

The implementation in CMake has:

set(CLANG_MIN 3.6)
set(CLANG_WARN 4.0)

If your intent is to warn people that their host compiler won't be supported in the next release, we don't need *two* levels here.

We absolutely do. For now, as we phase this in, you can opt out of the error. This is the one and only time you can do this. In the future, it'll be a hard error you can't opt out of, because we'll have moved past C++11. The "MIN" is *for now* a suggested minimum, but after LLVM 8 it'll be mandatory. This patch sets up our process, we need it.

Finally, that still left open the choice of which compiler version the "warning" is issued.

~1.5 years, which per policy can be updated after an llvm-dev discussion.

Thought it was *3* years before removing the support? (Also should be *motivated* by *benefits*)

~3 years for "MIN", ~1.5 years for "WARN". This hasn't changed since months ago in the discussion, I don't want to re-open it for debate.

[erichkeane]

Update branch date to match the 7.0.0 from 8.0.0 branch date.

[jfb]

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

[mehdi_amini]

In D47073#1358593, @jfb wrote:

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

I strongly disagree with this right now: this is *not* OK to rush this as is.

If you need something in the release, then it can be done in a much less controversial way.

[jfb]

In D47073#1358626, @mehdi_amini wrote:

In D47073#1358593, @jfb wrote:

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

I strongly disagree with this right now: this is *not* OK to rush this as is.

If you need something in the release, then it can be done in a much less controversial way.

What makes you say this is being rushed? I agree your participation to the discussion is new, but consider that the RFC was *months* ago (and wasn't the first or second time it was discussed), and so was the LLVM developer meeting discussion. There's agreement that we'll move away from C++11, soon. We'd be irresponsible if we didn't tell developers who build LLVM. That's the only thing the patch does: tell people what we've agreed to do (admittedly we don't have a fixed timeline because we're waiting on significant contributors being ready to move, but there's agreement nonetheless, tentatively end of 2019 Q1).

[mehdi_amini]

In D47073#1358640, @jfb wrote:

In D47073#1358626, @mehdi_amini wrote:

In D47073#1358593, @jfb wrote:

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

I strongly disagree with this right now: this is *not* OK to rush this as is.

If you need something in the release, then it can be done in a much less controversial way.

What makes you say this is being rushed?

The way you're trying to get this checked in with two reviewers requiring major changes that haven't been addressed.
The fact that the process of discussing which version of the compiler to bump to should happen *before* adding a check, and it hasn't happened for this patch which *actually* change the minimum versions.

There's agreement that we'll move away from C++11, soon. We'd be irresponsible if we didn't tell developers who build LLVM. That's the only thing the patch does: tell people what we've agreed to do?

1. I asked *multiple* times in this patch *why* and *how* these particular version of the compiler where picked. I still don't know why clang-3.5 would trigger a cmake error.
2. The two levels: cmake warn vs cmake error are *not* required to achieve what you're describing: i.e. warning people in LLVM 8 that LLVM 9 won't support their compiler. *One* level (cmake error) is plenty enough.

In D47073#1358066, @mehdi_amini wrote:

In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

[jfb]

In D47073#1358641, @mehdi_amini wrote:

In D47073#1358640, @jfb wrote:

In D47073#1358626, @mehdi_amini wrote:

In D47073#1358593, @jfb wrote:

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

I strongly disagree with this right now: this is *not* OK to rush this as is.

If you need something in the release, then it can be done in a much less controversial way.

What makes you say this is being rushed?

The way you're trying to get this checked in with two reviewers requiring major changes that haven't been addressed.

s/two/one/ : I've talked to Chandler already, and he was leaning on others (in large parts, me) to help Erich with the review. Further, Erich addressed your comments repeatedly. It seems like you're asking for more?

The fact that the process of discussing which version of the compiler to bump to should happen *before* adding a check, and it hasn't happened for this patch which *actually* change the minimum versions.

It happened months ago in the LLVM dev RFC, and was re-discussed in-person at the dev meeting.

There's agreement that we'll move away from C++11, soon. We'd be irresponsible if we didn't tell developers who build LLVM. That's the only thing the patch does: tell people what we've agreed to do?

1. I asked *multiple* times in this patch *why* and *how* these particular version of the compiler where picked. I still don't know why clang-3.5 would trigger a cmake error.

Read the email thread?

2. The two levels: cmake warn vs cmake error are *not* required to achieve what you're describing: i.e. warning people in LLVM 8 that LLVM 9 won't support their compiler. *One* level (cmake error) is plenty enough.

This is setting up something new. Yes, we could just have one level for now, but we'll add the second level as soon as we truly move off C++11 (this is clear in the policy!). The patch sets things up properly for the policy we're establishing. It's a boundary value problem, and like all good BVPs we're carving out a small boundary (here, at the initial impulse) to solve the wider problem. The policy is encoded in CMake.

In D47073#1358066, @mehdi_amini wrote:

In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

[lhames]

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

I strongly disagree with this right now: this is *not* OK to rush this as is.

If you need something in the release, then it can be done in a much less controversial way.

Given how long this has been discussed I don't feel like it is being rushed. On the contrary: I would really like to see us land this (or something very much like it in 8.0) to get this process moving.

The two levels: cmake warn vs cmake error are *not* required to achieve what you're describing: i.e. warning people in LLVM 8 that LLVM 9 won't support their compiler. *One* level (cmake error) is plenty enough.

This is setting up something new. Yes, we could just have one level for now, but we'll add the second level as soon as we truly move off C++11 (this is clear in the policy!). The patch sets things up properly for the policy we're establishing. It's a boundary value problem, and like all good BVPs we're carving out a small boundary (here, at the initial impulse) to solve the wider problem. The policy is encoded in CMake.

The specifics of how the warning/error are implemented seem like something we could revisit. I would much rather have some mechanism make it in to 8.0 to warn people about these changes, rather than put off any warnings for another release cycle.

[jyknight]

Firstly -- I agree we ought to put something in the LLVM 8.0 release. However, we do not need to get it committed *today* for it to make it into the 8.0 release. It can be cherry-picked to the branch after the branch-cut.

Secondly -- there seems to be some confusion still over what the new policy is. My understanding is that the time-based proposal is *rejected*, and that we're using "3 years old" only as a guideline for what compilers to support, not any sort of date cutoff. Therefore, I think we should be encoding two toolchain version requirements in the buildsystem:

1. The *actual* minimum version required. For the GCC toolchain, that is currently GCC 4.8.
2. The intended minimum version required for the next release of LLVM. (GCC 5, because we want C++14, and that's the first version that supports it).

I'd call those two values GCC_MIN and GCC_WARN -- and both should be cmake-level errors by default, because, as you say, a warning message would simply be ignored. The former is be an unconditional error (just as the existing error for GCC < 4.8 is), while the latter must be able to be disabled. This patch, as it stands, is missing #1, puts #2 in "GCC_MIN", and uses "GCC_WARN" as a non-fatal warning message, set to GCC 6.3. I don't think that GCC 6.3 is relevant to anything, so that last is unnecessary.

Finally, as the policy expressed in this commit states, and as mehdi has requested, an email should be sent to llvm-dev, setting out concretely what the new minimum compiler versions for LLVM 9 are intended to be, and why (comparing value vs harm). The most-recent email thread linked from this commit does NOT have this. I do recall seeing such things in other threads in the past, but the conclusion should be set out concretely, now.

[mehdi_amini]

In D47073#1358663, @jfb wrote:

s/two/one/ : I've talked to Chandler already, and he was leaning on others (in large parts, me) to help Erich with the review

I'm not gonna speak for him, I just still see a red mark on this patch, admittedly the patch has been updated since.

Further, Erich addressed your comments repeatedly. It seems like you're asking for more?

Yes, not everything has been addressed AFAICT: like how the specific version of the compilers have been picked.

The fact that the process of discussing which version of the compiler to bump to should happen *before* adding a check, and it hasn't happened for this patch which *actually* change the minimum versions.

It happened months ago in the LLVM dev RFC, and was re-discussed in-person at the dev meeting.

No: the RFC does not include this discussion. If you want to claim this, then please source it precisely.

There's agreement that we'll move away from C++11, soon. We'd be irresponsible if we didn't tell developers who build LLVM. That's the only thing the patch does: tell people what we've agreed to do?

1. I asked *multiple* times in this patch *why* and *how* these particular version of the compiler where picked. I still don't know why clang-3.5 would trigger a cmake error.

Read the email thread?

It does not motivate the reason to pick clang 3.6, and basing it *only* on the arbitrary time-based choice: this is not acceptable IMO.

This was mentioned in the RFC as well but unanswered AFAICT: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123261.html

[chandlerc]

I think there is a lot of confusion here, and frustration, and that is making it hard to make progress.

To help, I want to reiterate what James said: we do not have to land this patch *now* for it to be in the release. In fact, Hans already said he would prefer that this spend some time in trunk before being cherrypicked for the release (and I agree with his reasoning, and ultimately think it is his call).

While I agree with Lang that this has already dragged on a long time, I also think it *can* wait until we sort out the confusion without any harm. =D

A question came up about whether my concerns have been addressed. I did talk with JF, and he was working to get my primary concern addressed which was making it clear that the time based strategy isn't a rule. I think this has been mostly addressed.

However, I think Mehdi has raised some very valid points that I do agree with. The first concern is that the "minimum" and "warning" distinction is confusing, and I really do agree with him here. I was having trouble understanding it, but I think James summarized perfectly a good approach:

In D47073#1358937, @jyknight wrote:

Secondly -- there seems to be some confusion still over what the new policy is. My understanding is that the time-based proposal is *rejected*, and that we're using "3 years old" only as a guideline for what compilers to support, not any sort of date cutoff. Therefore, I think we should be encoding two toolchain version requirements in the buildsystem:

1. The *actual* minimum version required. For the GCC toolchain, that is currently GCC 4.8.
2. The intended minimum version required for the next release of LLVM. (GCC 5, because we want C++14, and that's the first version that supports it).

I'd call those two values GCC_MIN and GCC_WARN -- and both should be cmake-level errors by default, because, as you say, a warning message would simply be ignored. The former is be an unconditional error (just as the existing error for GCC < 4.8 is), while the latter must be able to be disabled.

I would draw a direct analogy to Clang's own diagnostics. One of these is an error, and it cannot be ignored. The other is a warning, but it is a warning that users will be unlikely to notice, so we use the CMake-analog to -Werror to make it an error, and if users need to move past it, they can disable the warning (much like you can with Clang).

This seems like a really reasonable strategy and to provide concrete benefits.

On the flip side, having a CMake warning for compilers 1.5y old doesn't (to me) provide any concrete benefit. As you say, the users will ignore them. So why implement logic for them? I think it just adds confusion to what we're trying to do here.

The second concern Mehdi raised James clearly seconded here:

Finally, as the policy expressed in this commit states, and as mehdi has requested, an email should be sent to llvm-dev, setting out concretely what the new minimum compiler versions for LLVM 9 are intended to be, and why (comparing value vs harm). The most-recent email thread linked from this commit does NOT have this. I do recall seeing such things in other threads in the past, but the conclusion should be set out concretely, now.

I agree as well. The old thread, while it has been out for some time, has likely not communicated this effectively. A fresh mail that concisely and succinctly lays out the goals/plans seems like a reasonable request and easily satisfied.

Mehdi raised a third concern that has not been addressed: add some of the criteria I suggested for how to make the actual decision to upgrade to the documentation so that it doesn't have to be repeated in each -dev thread discussing this every N releases. This doesn't seem as critical to me, but also seems useful and easily done.

Perhaps there are other things worth discussing, but I think at least these things currently have not been addressed and we don't have consensus here, so I think landing the patch remains a bit premature. I *also* am not worried about getting the resolution to the above worked out and into LLVM-8, so while I'm urging taking some more time, I do *not* think this will materially delay anything.

[erichkeane]

For what it's worth, the stricter version of this patch received quite overwhelming support in May. We delayed it due to Google's limitations and yet we still don't seem to have made progress. This current patch is a result of a continued set of compromises to try to satisfy a few in the vocal minority. I'd suggest that we all agree to have an ACTUAL decision made on llvm-dev, rather than this constant state of consensus derailed by vocal minority.

[chandlerc]

In D47073#1359266, @erichkeane wrote:

For what it's worth, the stricter version of this patch received quite overwhelming support in May. We delayed it due to Google's limitations and yet we still don't seem to have made progress. This current patch is a result of a continued set of compromises to try to satisfy a few in the vocal minority. I'd suggest that we all agree to have an ACTUAL decision made on llvm-dev, rather than this constant state of consensus derailed by vocal minority.

This *patch* does not matter to Google in any real sense that I'm aware of.... *All* of what I wrote in my latest comment is about this patch, and has nothing to do with the overall strategy of the LLVM project. And that feedback was given as a very active individual contributor to the project.

Does Google care a great deal about the overall state of host compiler support and C++ version support of LLVM? Yes, it does. We expressed that, and so did others. That was done on the -dev list as well as in the BoF. I'm not really interested in re-arguing it here.

But please try to take my feedback on this *patch* as just that. It is code review and feedback on the specific changes you are making. I'm genuinely trying to help get the CMake and documentation implementation *right* and useful for the project and the community, not for Google. I'm sorry that you're frustrated, I really am. But I am actually trying to help, and comments like this, IMO, are not constructive.

[mehdi_amini]

I don't want to give the impression I'm stalling this just for the sake of being difficult, and since it is easier to talk "with code" I quickly wrote this: https://reviews.llvm.org/D56770 . This *not* a patch intended to be submitted, it is just a stripped-down version of how I'd phrase/structure it intended to support my arguments in this thread. Note that I would intentionally left out any compiler minimum bump out of the policy upgrade change, as these are conceptually separate change anyway.

[jfb]

No: the RFC does not include this discussion. If you want to claim this, then please source it precisely.

This patch's description links to: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html

Which says:

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6. We would WARN on anything older than GCC7.1/Clang3.8

That 3 / 1.5 cutoff was discussed on this patch, e.g. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123249.html
and came from this discussion: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html
It started off as "which compilers give us the features we want" and modified itself into "for now we get what we want with a 3 year lookback, let's use that as a hand wavy policy going forward".

So I'd say that it was sourced quite precisely, and re-listing the entire discussion will lose all the bikeshedding minutia which led to where we are. At this point Erich is patiently trying to add nuance on top of nuance to a warning about a policy, pertaining to a discussion that's been going on for 7 months... So yes I totally see where the frustration comes from, all of that to migrate away from C++11 which has overwhelming support. I think it's critical to hard-warn (i.e. error with opt-out option) people in the LLVM 8 timeframe. Sure we can cherry-pick a patch, but the later we do so the more potential hurt there is. I'd really rather not shoulder that hurt, because I think it's better to just tell people compiling LLVM 8 now: we're going to move away from older compilers, get ready.

[erichkeane]

In D47073#1359273, @chandlerc wrote:

In D47073#1359266, @erichkeane wrote:

For what it's worth, the stricter version of this patch received quite overwhelming support in May. We delayed it due to Google's limitations and yet we still don't seem to have made progress. This current patch is a result of a continued set of compromises to try to satisfy a few in the vocal minority. I'd suggest that we all agree to have an ACTUAL decision made on llvm-dev, rather than this constant state of consensus derailed by vocal minority.

This *patch* does not matter to Google in any real sense that I'm aware of.... *All* of what I wrote in my latest comment is about this patch, and has nothing to do with the overall strategy of the LLVM project. And that feedback was given as a very active individual contributor to the project.

Does Google care a great deal about the overall state of host compiler support and C++ version support of LLVM? Yes, it does. We expressed that, and so did others. That was done on the -dev list as well as in the BoF. I'm not really interested in re-arguing it here.

But please try to take my feedback on this *patch* as just that. It is code review and feedback on the specific changes you are making. I'm genuinely trying to help get the CMake and documentation implementation *right* and useful for the project and the community, not for Google. I'm sorry that you're frustrated, I really am. But I am actually trying to help, and comments like this, IMO, are not constructive.

I acknowledge that you have different concerns than you did previously. I would simply like us to once and for all define what the acceptance criteria are for a patch like this. The fact that we have had a dozen llvm-dev conversations with overwhelming consensus blocked by a few vocal people is concerning.

This patch for example has been watered down excessively from a version with extensive support (the community minus vaguely 3) in an atempt to gain unanimous consent. However, despite multiple consessions, we've gained no support.

Is "a significant majority of the community" sufficent (in which case where we foolish to try to placate nay Sayers), or do we require unanimous consent?

Many of us conceded to delay any such decision on something like this due to Google's concerns, which was my point earlier. Now that they seem less concerned, I'd imagined we would be less blocked. Instead, I notice that the consessions we made to placate a few have resulted in yet another denial of progress.

I am admittedly quite discouraged and frustrated, since this effort is constantly derailed by a vaguely defined and frequently changing process.

So I guess what I want is: how do we meaningfully progress this project? How do we prevent ourselves from being derailed by making consessions to the vocal minority? This patch had a meaningful amount of support in May as a much stronger and sane patch. Yet, these consessions made to the few critics are now the reason to reject it. How do I avoid that next time?

[mehdi_amini]

I can't add much more than what @jyknight wrote here: https://reviews.llvm.org/D47073#1358937 ; this summarize perfectly my view of the situation.

In D47073#1359315, @jfb wrote:

No: the RFC does not include this discussion. If you want to claim this, then please source it precisely.

This patch's description links to: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html

Which says:

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6. We would WARN on anything older than GCC7.1/Clang3.8

I thought you were OK with the fact that a pure time-based motivation wasn't enough?

That 3 / 1.5 cutoff was discussed on this patch, e.g. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123249.html
and came from this discussion: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html

Thanks for this last link, I couldn't find it nowhere in this review, and it isn't in the RFC thread that is linked from here. This last discussion is spot-on what I asked for (multiple times) to justify the versions!
(EDIT: I just figured that it is linked *from your abandoned revision*, but not directly from the RFC or from here)

Unfortunately, the thread ends up with: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123268.html ; which is very close to what I'm asking for.

I feel the work of summarizing the choice of the version of compilers has *not* been done and I'm still under the impression. the versions in this patch has been picked on the 3-y time-based and not on the support they provide.

(you mentioned clang 3.4 here by the way: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123247.html )

[jfb]

In D47073#1359335, @mehdi_amini wrote:

I can't add much more than what @jyknight wrote here: https://reviews.llvm.org/D47073#1358937 ; this summarize perfectly my view of the situation.

In D47073#1359315, @jfb wrote:

No: the RFC does not include this discussion. If you want to claim this, then please source it precisely.

This patch's description links to: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html

Which says:

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6. We would WARN on anything older than GCC7.1/Clang3.8

I thought you were OK with the fact that a pure time-based motivation wasn't enough?

That 3 / 1.5 cutoff was discussed on this patch, e.g. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123249.html
and came from this discussion: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html

Thanks for this last link, I couldn't find it nowhere in this review, and it isn't in the RFC thread that is linked from here. This last discussion is spot-on what I asked for (multiple times) to justify the versions!
(EDIT: I just figured that it is linked *from your abandoned revision*, but not directly from the RFC or from here)

Unfortunately, the thread ends up with: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123268.html ; which is very close to what I'm asking for.

I feel the work of summarizing the choice of the version of compilers has *not* been done and I'm still under the impression. the versions in this patch has been picked on the 3-y time-based and not on the support they provide.

(you mentioned clang 3.4 here by the way: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123247.html )

This review has unfortunately devolved into something totally unhelpful and unlikely to go anywhere. I don't think this is how an open-source project should work. I suggest we abandon this thread. I'll start a separate llvm-dev thread and new patches to get this back on track.

[erichkeane]

This patch has run its course.

[jyknight]

In D47073#1359998, @jfb wrote:

I suggest we abandon this thread. I'll start a separate llvm-dev thread and new patches to get this back on track.

I concur that going back to the mailing list thread is appropriate. From my POV, the core problem here seems to be that the change from "date-based" to "requirements-based" was not truly agreed upon, despite the wording in this patch being updated to say it.

That needs to be resolved before reviving a patch. Are we:

1. Choosing versions based on being 3 years old, or,
2. Choosing versions based on their feature-set (e.g. C++14 support right now).

From the last few comments, it would appear that both Erich and JF both continue to feel that the former should be the policy. And arguing about details when there seems to remain disagreement over that issue is obviously not working.

[jfb]

In D47073#1360048, @jyknight wrote:

In D47073#1359998, @jfb wrote:

I suggest we abandon this thread. I'll start a separate llvm-dev thread and new patches to get this back on track.

I concur that going back to the mailing list thread is appropriate. From my POV, the core problem here seems to be that the change from "date-based" to "requirements-based" was not truly agreed upon, despite the wording in this patch being updated to say it.

That needs to be resolved before reviving a patch. Are we:

1. Choosing versions based on being 3 years old, or,
2. Choosing versions based on their feature-set (e.g. C++14 support right now).

From the last few comments, it would appear that both Erich and JF both continue to feel that the former should be the policy. And arguing about details when there seems to remain disagreement over that issue is obviously not working.

That's incorrect. I don't care what the policy is as long as it's sane. 3 years was proposed on the RFC, we went with it. Then nuance was asked for on this review, we went with it. Then it was asked that time was made a soft constraint, we went with it. Then more bikeshed happened. The version was absolutely chosen based on agreement that we're moving off C++11, and C++14 is the next version over. My updated email and patches will be clear on this, and I urge you Mehdi, and Chandler to try to drive this to a resolution ASAP. I think it would be unacceptable if LLVM 8 didn't have a soft-error, and I think the longer we want to cherry-pick such soft-error the more irresponsible we are.

[mehdi_amini]

In D47073#1360077, @jfb wrote:

That's incorrect. I don't care what the policy is as long as it's sane. 3 years was proposed on the RFC, we went with it. Then nuance was asked for on this review, we went with it. Then it was asked that time was made a soft constraint, we went with it. Then more bikeshed happened.

This is a misrepresentation of what happened.
I can give you an alternative version but your attitude in this thread does not lead me to think you'd listen.

The version was absolutely chosen based on agreement that we're moving off C++11, and C++14 is the next version over.

This is not true.

If all you want is C++14 and a warning in LLVM 8.0, the path was fairly clear to me: properly address reviews, don't ignore questions when they don't serve your agenda, and finally don't rush patches when there are controversial points unadressed.
If you think that's how an open source project should work, I think we'll run into more dead-ends.

[jfb]

In D47073#1360116, @mehdi_amini wrote:

In D47073#1360077, @jfb wrote:

That's incorrect. I don't care what the policy is as long as it's sane. 3 years was proposed on the RFC, we went with it. Then nuance was asked for on this review, we went with it. Then it was asked that time was made a soft constraint, we went with it. Then more bikeshed happened.

This is a misrepresentation of what happened.
I can give you an alternative version but your attitude in this thread does not lead me to think you'd listen.

The version was absolutely chosen based on agreement that we're moving off C++11, and C++14 is the next version over.

This is not true.

If all you want is C++14 and a warning in LLVM 8.0, the path was fairly clear to me: properly address reviews, don't ignore questions when they don't serve your agenda, and finally don't rush patches when there are controversial points unadressed.
If you think that's how an open source project should work, I think we'll run into more dead-ends.

This is not a constructive response, and I don't intend to keep replying to this thread. As I've said, this review is past its usefulness. In the follow-up, please avoid ascribing ill-intent to what I'm doing. Specifically, "misrepresentation", "you'd listen", "ignore questions", "serve your agenda", "rush patches", "controversial", are all phrases that I find don't lead to a productive discussion.

[jfb]

Please see https://reviews.llvm.org/D56819 for the policy discussion.

CMakeLists.txt

if(NOT DEFINED LLVM_VERSION_MINOR)
   set(LLVM_VERSION_MINOR 0)
 endif()
 if(NOT DEFINED LLVM_VERSION_PATCH)
   set(LLVM_VERSION_PATCH 0)
 endif()
 if(NOT DEFINED LLVM_VERSION_SUFFIX)
   set(LLVM_VERSION_SUFFIX svn)
 endif()
+if (NOT DEFINED LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK)
+  set(LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK OFF)
+endif()
 
 if (NOT PACKAGE_VERSION)
   set(PACKAGE_VERSION
     "${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}")
 endif()
 
 if ((CMAKE_GENERATOR MATCHES "Visual Studio") AND (CMAKE_GENERATOR_TOOLSET STREQUAL ""))
   message(WARNING "Visual Studio generators use the x86 host compiler by "

cmake/modules/CheckCompilerVersion.cmake

-# Check if the host compiler is new enough. LLVM requires at least GCC 4.8,
-# MSVC 2015 (Update 3), or Clang 3.1.
+# Check if the host compiler is new enough.  For MSVC, LLVM requires at least
+# MSVC 2015 (Update 3).  For GCC and Clang, LLVM's rough guideline is to support
+# all major compiler versions released about 3 years from the date in which the
+# previous version was branched. This time-based guideline is not strict; we
+# want to keep some discretion when supporting older compilers still makes
+# sense, or when newer compilers inflict significant pain. Additionally, a CMake
+# warning is issued for versions older than 1.5 years.
+
+# Before updating the minimum versions, LLVM's policy requires an LLVM-Dev
+# mailing list discussion.  This discussion should revolve around the value the
+# update brings to the LLVM project as well as any harm it causes to LLVM's
+# users, consumers, and developers. However, a lack of significant harm should
+# not be construed as sufficient reason to alter these minimums.
+
+# For current LLVM trunk (version 8.0), the effective date is August 1st, 2018.
 
 include(CheckCXXSourceCompiles)
 
+set(GCC_MIN 5.2)
+set(GCC_WARN 6.3)
+set(CLANG_MIN 3.6)
+set(CLANG_WARN 4.0)
+set(APPLECLANG_MIN 7.3)
+set(APPLECLANG_WARN 8.1)
+
 if(NOT DEFINED LLVM_COMPILER_CHECKED)
   set(LLVM_COMPILER_CHECKED ON)
 
   if(NOT LLVM_FORCE_USE_OLD_TOOLCHAIN)
     if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
-      if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.8)
-        message(FATAL_ERROR "Host GCC version must be at least 4.8!")
+      if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS GCC_MIN
+         AND NOT LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK)
+        # These error messages should change to be "is unsupported" once LLVM moves past
+        # C++11 support. We currently leave this as "will soon be unsupported" 
+        # plus an option to reduce it to a warning to give users time to convert
+        # their environments. 
+        message(FATAL_ERROR "GCC ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported "
+                "(minimum version is GCC ${GCC_MIN}). Compiler version checking"
+                " can be ignored with the cmake option LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK.")
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS GCC_MIN)
+        message(WARNING "GCC ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported "
+                "(minimum version is GCC ${GCC_MIN}).")
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS GCC_WARN)
+        message(WARNING "GCC ${CMAKE_CXX_COMPILER_VERSION} will soon be "
+                        " unsupported (version < GCC ${GCC_WARN}).")
+      endif()
+    elseif(CMAKE_CXX_COMPILER_ID STREQUAL "AppleClang")
+      if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS APPLECLANG_MIN
+         AND NOT LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK)
+        message(FATAL_ERROR "Apple-Clang ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported "
+                "(minimum version is Apple-Clang ${APPLECLANG_MIN}). Compiler version "
+                "checking can be ignored with the cmake option "
+                "LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK.")
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS APPLECLANG_MIN)
+        message(WARNING "Apple-Clang ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported "
+                "(minimum version is Apple-Clang ${APPLECLANG_MIN}).")
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS APPLECLANG_WARN)
+        message(WARNING "Apple-Clang ${CMAKE_CXX_COMPILER_VERSION} will soon be "
+                "unsupported (version < Apple-Clang ${APPLECLANG_WARN}).")
       endif()
     elseif(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
-      if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 3.1)
-        message(FATAL_ERROR "Host Clang version must be at least 3.1!")
+      if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS CLANG_MIN
+         AND NOT LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK)
+        message(FATAL_ERROR "Clang ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported "
+                "(minimum version is Clang ${CLANG_MIN}). Compiler version "
+                "checking can be ignored with the cmake option "
+                "LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK.")
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS CLANG_MIN)
+        message(WARNING "Clang ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported "
+                "(minimum version is Clang ${CLANG_MIN}).")
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS CLANG_WARN)
+        message(WARNING "Clang ${CMAKE_CXX_COMPILER_VERSION} will soon be "
+                "unsupported (version < Clang ${CLANG_WARN}).")
       endif()
 
       if (CMAKE_CXX_SIMULATE_ID MATCHES "MSVC")
         if (CMAKE_CXX_SIMULATE_VERSION VERSION_LESS 19.0)
           message(FATAL_ERROR "Host Clang must have at least -fms-compatibility-version=19.0")
         endif()
         set(CLANG_CL 1)
       elseif(NOT LLVM_ENABLE_LIBCXX)

 int main() { return (float)x; }"
           LLVM_NO_OLD_LIBSTDCXX)
         if(NOT LLVM_NO_OLD_LIBSTDCXX)
           message(FATAL_ERROR "Host Clang must be able to find libstdc++4.8 or newer!")
         endif()
         set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
         set(CMAKE_REQUIRED_LIBRARIES ${OLD_CMAKE_REQUIRED_LIBRARIES})
       endif()
     elseif(CMAKE_CXX_COMPILER_ID MATCHES "MSVC")
       if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.0)
         message(FATAL_ERROR "Host Visual Studio must be at least 2015")
       elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS 19.00.24213.1)
         message(WARNING "Host Visual Studio should at least be 2015 Update 3 (MSVC 19.00.24213.1)"
           "  due to miscompiles from earlier versions")
       endif()
     endif()
   endif()
 endif()

docs/CMake.rst

 **LLVM_CCACHE_BUILD**:BOOL
   If enabled and the ``ccache`` program is available, then LLVM will be
   built using ``ccache`` to speed up rebuilds of LLVM and its components.
   Defaults to OFF.  The size and location of the cache maintained
   by ``ccache`` can be adjusted via the LLVM_CCACHE_MAXSIZE and LLVM_CCACHE_DIR
   options, which are passed to the CCACHE_MAXSIZE and CCACHE_DIR environment
   variables, respectively.
 
+**LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK**:BOOL
+  If enabled, the CMake checks for Clang and GCC minimum host compiler versions
+  will be ignored. This flag will likely be removed for LLVM 9.0 due to a bump
+  in the required C++ version. This defaults to OFF.
+
 CMake Caches
 ============
 
 Recently LLVM and Clang have been adding some more complicated build system
 features. Utilizing these new features often involves a complicated chain of
 CMake variables passed on the command line. Clang provides a collection of CMake
 cache scripts to make these features more approachable.
 

docs/CodingStandards.rst

 working as expected until some build bot tells you otherwise. If you're in an
 uncertain area of one of the above points, but you cannot test on a Linux
 system, your best approach is to minimize your use of these features, and watch
 the Linux build bots to find out if your usage triggered a bug. For example, if
 you hit a type trait which doesn't work we can then add support to LLVM's
 traits header to emulate it.
 
 .. _the libstdc++ manual:
-  https://gcc.gnu.org/onlinedocs/gcc-4.8.0/libstdc++/manual/manual/status.html#status.iso.2011
+  https://gcc.gnu.org/onlinedocs/gcc-5.2.0/libstdc++/manual/manual/status.html#status.iso.2011
 
 Other Languages
 ---------------
 
 Any code written in the Go programming language is not subject to the
 formatting rules below. Instead, we adopt the formatting rules enforced by
 the `gofmt`_ tool.
 

docs/GettingStarted.rst

 for the software package that LLVM depends on. The Version column provides
 "known to work" versions of the package. The Notes column describes how LLVM
 uses the package and provides other details.
 
 =========================================================== ============ ==========================================
 Package                                                     Version      Notes
 =========================================================== ============ ==========================================
 `GNU Make <http://savannah.gnu.org/projects/make>`_         3.79, 3.79.1 Makefile/build processor
-`GCC <http://gcc.gnu.org/>`_                                >=4.8.0      C/C++ compiler\ :sup:`1`
+`GCC <https://gcc.gnu.org/>`_                               >=5.2.0      C/C++ compiler\ :sup:`1`
 `python <http://www.python.org/>`_                          >=2.7        Automated test suite\ :sup:`2`
 `zlib <http://zlib.net>`_                                   >=1.2.3.4    Compression library\ :sup:`3`
 =========================================================== ============ ==========================================
 
 .. note::
 
    #. Only the C and C++ languages are needed so there's no need to build the
       other languages for LLVM's purposes. See `below` for specific version

 
 .. _below:
 .. _check here:
 
 Host C++ Toolchain, both Compiler and Standard Library
 ------------------------------------------------------
 
 LLVM is very demanding of the host C++ compiler, and as such tends to expose
-bugs in the compiler. We are also planning to follow improvements and
-developments in the C++ language and library reasonably closely. As such, we
-require a modern host C++ toolchain, both compiler and standard library, in
-order to build LLVM.
+bugs in the compiler. We also attempt to follow improvements and developments in
+the C++ language and library reasonably closely. As such, we require a modern
+host C++ toolchain, both compiler and standard library, in order to build LLVM.
 
 For the most popular host toolchains we check for specific minimum versions in
 our build systems:
 
-* Clang 3.1
-* GCC 4.8
+* Clang 3.6
+* Apple-Clang 7.3
+* GCC 5.2
 * Visual Studio 2015 (Update 3)
 
+For GCC and Clang, LLVM's guideline is to support all major compiler versions
+released at least 3 years from the date in which the previous version was
+branched. This time-based guideline is not strict; we will balance the benefits
+to drop support for older compilers in terms of features available for
+development with the availability of more recent versions on the most widely
+used platforms (for example considering Ubuntu LTS, etc.).
+
 Anything older than these toolchains *may* work, but will require forcing the
 build system with a special option and is not really a supported host platform.
 Also note that older versions of these compilers have often crashed or
-miscompiled LLVM.
+miscompiled LLVM. The checks can be ignored with the cmake option
+LLVM_IGNORE_HOST_COMPILER_VERSION_CHECK.
 
 For less widely used host toolchains such as ICC or xlC, be aware that a very
 recent version may be required to support all of the C++ features used in LLVM.
 
 We track certain versions of software that are *known* to fail when used as
 part of the host toolchain. These even include linkers at times.
 
 **GNU ld 2.16.X**. Some 2.16.X versions of the ld linker will produce very long

 well tested or set up to build on Linux until relatively recently. As
 a consequence, this guide suggests just using libstdc++ and a modern GCC as the
 initial host in a bootstrap, and then using Clang (and potentially libc++).
 
 The first step is to get a recent GCC toolchain installed. The most common
 distribution on which users have struggled with the version requirements is
 Ubuntu Precise, 12.04 LTS. For this distribution, one easy option is to install
 the `toolchain testing PPA`_ and use it to install a modern GCC. There is
-a really nice discussions of this on the `ask ubuntu stack exchange`_. However,
-not all users can use PPAs and there are many other distributions, so it may be
-necessary (or just useful, if you're here you *are* doing compiler development
-after all) to build and install GCC from source. It is also quite easy to do
-these days.
+a really nice discussions of this on the `ask ubuntu stack exchange`_ and a
+`github gist`_ with updated commands. However, not all users can use PPAs and
+there are many other distributions, so it may be necessary (or just useful, if
+you're here you *are* doing compiler development after all) to build and install
+GCC from source. It is also quite easy to do these days.
 
 .. _toolchain testing PPA:
   https://launchpad.net/~ubuntu-toolchain-r/+archive/test
 .. _ask ubuntu stack exchange:
-  http://askubuntu.com/questions/271388/how-to-install-gcc-4-8-in-ubuntu-12-04-from-the-terminal
+  https://askubuntu.com/questions/466651/how-do-i-use-the-latest-gcc-on-ubuntu/581497#58149
+.. _github gist:
+  https://gist.github.com/application2000/73fd6f4bf1be6600a2cf9f56315a2d91
 
-Easy steps for installing GCC 4.8.2:
+Easy steps for installing GCC 5.2.0:
 
 .. code-block:: console
 
-  % wget https://ftp.gnu.org/gnu/gcc/gcc-4.8.2/gcc-4.8.2.tar.bz2
-  % wget https://ftp.gnu.org/gnu/gcc/gcc-4.8.2/gcc-4.8.2.tar.bz2.sig
+  % wget https://ftp.gnu.org/gnu/gcc/gcc-5.2.0/gcc-5.2.0.tar.bz2
+  % wget https://ftp.gnu.org/gnu/gcc/gcc-5.2.0/gcc-5.2.0.tar.bz2.sig
   % wget https://ftp.gnu.org/gnu/gnu-keyring.gpg
-  % signature_invalid=`gpg --verify --no-default-keyring --keyring ./gnu-keyring.gpg gcc-4.8.2.tar.bz2.sig`
+  % signature_invalid=`gpg --verify --no-default-keyring --keyring ./gnu-keyring.gpg gcc-5.2.0.tar.bz2.sig`
   % if [ $signature_invalid ]; then echo "Invalid signature" ; exit 1 ; fi
-  % tar -xvjf gcc-4.8.2.tar.bz2
-  % cd gcc-4.8.2
+  % tar -xvjf gcc-5.2.0.tar.bz2
+  % cd gcc-5.2.0
   % ./contrib/download_prerequisites
   % cd ..
-  % mkdir gcc-4.8.2-build
-  % cd gcc-4.8.2-build
-  % $PWD/../gcc-4.8.2/configure --prefix=$HOME/toolchains --enable-languages=c,c++
+  % mkdir gcc-5.2.0-build
+  % cd gcc-5.2.0-build
+  % $PWD/../gcc-5.2.0/configure --prefix=$HOME/toolchains --enable-languages=c,c++
   % make -j$(nproc)
   % make install
 
 For more details, check out the excellent `GCC wiki entry`_, where I got most
 of this information from.
 
 .. _GCC wiki entry:
-  http://gcc.gnu.org/wiki/InstallingGCC
+  https://gcc.gnu.org/wiki/InstallingGCC
 
 Once you have a GCC toolchain, configure your build of LLVM to use the new
 toolchain for your host compiler and C++ standard library. Because the new
 version of libstdc++ is not on the system library search path, you need to pass
 extra linker flags so that it can be found at link time (``-L``) and at runtime
 (``-rpath``). If you are using CMake, this invocation should produce working
 binaries: