Bump minimum toolchain version

[jfb]

Summary

The RFC on moving past C++11 got good traction:

http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:

llvm.org/docs/DeveloperPolicy.html#toolchain

We’ll only migrate to hard-error (and start using new features) when we get consensus to do so, at the earliest end of March 2019. The patch will allow us to start warning developers, especially those who only compile branches (in this case, LLVM 8).

[smeenai]

CMakeLists.txt

26 ↗

(On Diff #183647)

Might wanna make this an option and define it with all the other options?

docs/GettingStarted.rst

303 ↗

(On Diff #183647)

Should this be 5.1?

[jfb]

• Fix typo.

[jfb]

CMakeLists.txt

26 ↗

(On Diff #183647)

What do you mean?

[smeenai]

CMakeLists.txt

26 ↗

(On Diff #183647)

I meant a CMake option, similar to how LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN (which appears unused now) is defined: https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/CMakeLists.txt$386-387

[jfb]

• Use an option.

[jfb]

CMakeLists.txt

26 ↗

(On Diff #183647)

Ah gotcha! Fixed (and drive-by fix LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN to LLVM_FORCE_USE_OLD_TOOLCHAIN).

[jyknight]

docs/GettingStarted.rst

231 ↗

(On Diff #183663)

I think we should keep the documentation saying the actual minimum version, too. Maybe:

We recommend (and will require in the next release) at least:
<new version list>

We require at least:
<old version list>

[jfb]

• Mention older versions too.

[jfb]

docs/GettingStarted.rst

231 ↗

(On Diff #183663)

Great point, changed!

[jyknight]

OK, let's do it.

But better watch the buildbots to see if any get broken by the new requirements (hopefully we have at least one that will be?), and add the extra_cmake_args as needed.

[jfb]

In D57264#1374596, @jyknight wrote:

OK, let's do it.

But better watch the buildbots to see if any get broken by the new requirements (hopefully we have at least one that will be?), and add the extra_cmake_args as needed.

You mean: pass a cmake argument so the buildbots don't fail? That would seem to defeat the purpose, no?

[hubert.reinterpretcast]

cmake/modules/CheckCompilerVersion.cmake

65 ↗

(On Diff #183954)

libstdc++4.8 should also warn now, right?

[jfb]

• Detect libstdc++ version.

[jfb]

@jyknight can you confirm that this latest change works for you? I think it's exactly your environment :)

cmake/modules/CheckCompilerVersion.cmake

65 ↗

(On Diff #183954)

The comment above was pretty bad... Updated to use __GLIBCXX__.

[hubert.reinterpretcast]

cmake/modules/CheckCompilerVersion.cmake

90 ↗

(On Diff #183971)

Typo: "support.Ignoring".

65 ↗

(On Diff #183954)

Thanks for the fix!

[jfb]

• Missing space.

[jyknight]

In D57264#1374606, @jfb wrote:

In D57264#1374596, @jyknight wrote:

OK, let's do it.

But better watch the buildbots to see if any get broken by the new requirements (hopefully we have at least one that will be?), and add the extra_cmake_args as needed.

You mean: pass a cmake argument so the buildbots don't fail? That would seem to defeat the purpose, no?

We need to be aware of which of the llvm project's official buildbots need upgrading. If any are broken, ISTM that the best thing to do is to mark each such individual bot that needs to be upgraded by setting the the LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN cmake argument in the buildbot configuration, to allow them to continue to build. Then, we know where things stand, and over the next month, the owners can upgrade as necessary, without it being an emergency.

Well, really, we should probably have at least one bot using the old version intentionally (assuming there are any now), so we can continue testing it until it's desupported.

The other options -- leaving bots broken (and unable to test any other changes) until someone can get around to upgrading it, or reverting this commit until all bots all been upgraded -- seem strictly worse.

[jyknight]

In D57264#1374659, @jfb wrote:

@jyknight can you confirm that this latest change works for you? I think it's exactly your environment :)

Well, the environment in question doesn't actually use CMake, so this change won't affect it.

[danilaml]

docs/GettingStarted.rst

236 ↗

(On Diff #183986)

Above or below?

[jfb]

• Above / below

[jfb]

In D57264#1374934, @jyknight wrote:

In D57264#1374659, @jfb wrote:

@jyknight can you confirm that this latest change works for you? I think it's exactly your environment :)

Well, the environment in question doesn't actually use CMake, so this change won't affect it.

Ah right!

In D57264#1374902, @jyknight wrote:

In D57264#1374606, @jfb wrote:

In D57264#1374596, @jyknight wrote:

OK, let's do it.

But better watch the buildbots to see if any get broken by the new requirements (hopefully we have at least one that will be?), and add the extra_cmake_args as needed.

You mean: pass a cmake argument so the buildbots don't fail? That would seem to defeat the purpose, no?

We need to be aware of which of the llvm project's official buildbots need upgrading. If any are broken, ISTM that the best thing to do is to mark each such individual bot that needs to be upgraded by setting the the LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN cmake argument in the buildbot configuration, to allow them to continue to build. Then, we know where things stand, and over the next month, the owners can upgrade as necessary, without it being an emergency.

Well, really, we should probably have at least one bot using the old version intentionally (assuming there are any now), so we can continue testing it until it's desupported.

The other options -- leaving bots broken (and unable to test any other changes) until someone can get around to upgrading it, or reverting this commit until all bots all been upgraded -- seem strictly worse.

Maybe I'm missing something obvious... do we have a buildbot configuration? I just looked at some bots and I see them running cmake with e.g.:

cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_TESTS=ON -DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_OPTIMIZED_TABLEGEN=ON -DCLANG_BUILD_EXAMPLES=OFF -GNinja -DLLVM_ENABLE_WERROR=OFF -DCMAKE_INSTALL_PREFIX=../../install/stage1 '-DLLVM_LIT_ARGS="-v"' ../../llvm

or

cmake -GNinja '-DLLVM_ENABLE_PROJECTS=clang;lld' '-DLLVM_ENABLE_RUNTIMES=compiler-rt;libcxx;libcxxabi;libunwind' -DBOOTSTRAP_LLVM_ENABLE_LTO=OFF -DLLVM_ENABLE_LTO=OFF -DCMAKE_INSTALL_PREFIX=/b/fuchsia-x86_64-linux/llvm.install -DFUCHSIA_SDK=/b/fuchsia-x86_64-linux/fuchsia.sdk -C../llvm.src/clang/cmake/caches/Fuchsia.cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_WERROR=ON -DLLVM_OPTIMIZED_TABLEGEN=ON ../llvm.src/llvm

To speed things up I just audited *all* bots in http://lab.llvm.org:8011/buildslaves (there's so many!). Some of them are down, I therefore have no idea what they run. Here are the bots that will definitely break, with their maintainers:

Galina Kistanova <[e-mail]> @gkistanova
am1i-slv1 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
as-bldslv4 -- Microsoft (R) Visual Studio (R) 2015 (14.0)
ps4-buildslave2 -- Microsoft (R) Visual Studio (R) 2015 (14.0)

Hexagon QA <[e-mail]> @kparzysz @colinl
hexagon-build-02 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
hexagon-build-03 -- gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2

Vitaly Buka <[e-mail]> @vitalybuka
sanitizer-buildbot6 -- gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4

Reid Kleckner <[e-mail]> @rnk
sanitizer-windows -- Microsoft (R) Visual Studio (R) 2015 (14.0)

Ilia Taraban <[e-mail]> @itaraban
windows7-buildbot -- Microsoft (R) Visual Studio (R) 2015 (14.0)

To expedite things I've tagged them above, and Im going to email them individually so that they either pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to their bots, update the bot to a newer compiler version, or entirely turn down their bot.

[jfb]

Update: all the bots *except* @gkistanova's and @itaraban's are updated.

[jfb]

In D57264#1377635, @jfb wrote:

Update: all the bots *except* @gkistanova's and @itaraban's are updated.

All the bots should now be updated! Unless there are any new comments, I'll commit this tomorrow.

[rnk]

I didn't finish updating sanitizer-windows and I have no more time to work on bot maintenance this week (trainings + new team member). If you want to set the cmake option to warn instead of letting the bot go red, I'd appreciate it.

[hubert.reinterpretcast]

cmake/modules/CheckCompilerVersion.cmake

73 ↗

(On Diff #184109)

I can find __GLIBCXX__ on GCC 6.x toolchains, but I haven't found it on older ones.

#include <ciso646>
extern char x[__GLIBCXX__]; // error: '__GLIBCXX__' was not declared in this scope

[danilaml]

cmake/modules/CheckCompilerVersion.cmake

73 ↗

(On Diff #184109)

It seems to be there but it looks like "#include <ciso646>" doesn't define it for older compilers for some reason.

[hubert.reinterpretcast]

cmake/modules/CheckCompilerVersion.cmake

73 ↗

(On Diff #184109)

Yes, I see it now. The other thing is that maybe we could check the libstdc++ version for the other-than-known compilers as well (i.e., if we detect libstdc++, then check the version). Although that could be a later patch.

[jfb]

• Use iosfwd instead of ciso646 to find GLIBCXX, and don't use an apostrophe in the error message.

[jfb]

Interesting that libstdc++ wasn't including its own config file in ciso646! I tested it out in godbolt, and iosfwd seems to have that config in all the versions.

[jfb]

In D57264#1378370, @rnk wrote:

I didn't finish updating sanitizer-windows and I have no more time to work on bot maintenance this week (trainings + new team member). If you want to set the cmake option to warn instead of letting the bot go red, I'd appreciate it.

Apologies, I'd misunderstood our earlier conversation. Where would I make a change to affect your bots' cmake setup?

[jfb]

In D57264#1378812, @jfb wrote:

In D57264#1378370, @rnk wrote:

I didn't finish updating sanitizer-windows and I have no more time to work on bot maintenance this week (trainings + new team member). If you want to set the cmake option to warn instead of letting the bot go red, I'd appreciate it.

Apologies, I'd misunderstood our earlier conversation. Where would I make a change to affect your bots' cmake setup?

@jyknight directed me, here's the fix: D57525

[jfb]

Everything should now be in place. Speak soon or forever hold your peace 😉

[jfb]

Reverted in r352814 because some bots are still breaking. I'm contacting their authors and will try again soon.

[jfb]

@arsenm pointed me at his output. At a minimum, check_cxx_source_compiles does a compile, so I need to add main to all of these! That'll fix some of the issues, but I think some of the bots were still sad even with that fix.

[jfb]

• Add main to libstdc++ test.

[jfb]

I looked through the bots that failed, and it seems they were all hitting this. There might be bots that didn't pick up the change between my commit and the revert though. I'll wait a bit for the pipeline to clear, and I'll resubmit the patch with the fixed main.

[jfb]

Reverted again in r352835, looks like we still have some sad bots. I'll look into it!

[jfb]

• Relax libstdc++ check as suggested by @jyknight, it'll make odd configurations less sad.

[jfb]

Reverted for (I hope) the last time because of:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang. Once fixed the toolchain bump should stick.

[jfb]

In D57264#1381951, @jfb wrote:

Reverted for (I hope) the last time because of:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang. Once fixed the toolchain bump should stick.

I haven't heard back from bot owners. I'll opt them out of the toolchain checks for now: https://reviews.llvm.org/D57701

[jfb]

In D57264#1383646, @jfb wrote:

In D57264#1381951, @jfb wrote:

Reverted for (I hope) the last time because of:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang. Once fixed the toolchain bump should stick.

I haven't heard back from bot owners. I'll opt them out of the toolchain checks for now: https://reviews.llvm.org/D57701

The bots haven't updated yet, I sent a ping to @gkistanova, @grosser and @adasgupt.

[jfb]

In D57264#1385384, @jfb wrote:

In D57264#1383646, @jfb wrote:

In D57264#1381951, @jfb wrote:

Reverted for (I hope) the last time because of:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang. Once fixed the toolchain bump should stick.

I haven't heard back from bot owners. I'll opt them out of the toolchain checks for now: https://reviews.llvm.org/D57701

The bots haven't updated yet, I sent a ping to @gkistanova, @grosser and @adasgupt.

Bots were restarted, trying again...

[jfb]

Looks like clang-with-lto-ubuntu is still on an old version of GCC. Let's see if more bots are broken, I'm not sure how many stragglers we have.

[jfb]

Regarding libstdc++: the check is currently conservatively correct, but not thorough enough, because older revisions of GCC still get bug fix release which pass the date check. Past GCC 7 we can use _GLIBCXX_RELEASE, but before this @tstellar points out how LLDB does it. I don't know if we have to fix this issue: we simply fail to warn a small subset of libstdc++ users.

[hubert.reinterpretcast]

In D57264#1389686, @jfb wrote:

Regarding libstdc++: the check is currently conservatively correct, but not thorough enough, because older revisions of GCC still get bug fix release which pass the date check. Past GCC 7 we can use _GLIBCXX_RELEASE, but before this @tstellar points out how LLDB does it. I don't know if we have to fix this issue: we simply fail to warn a small subset of libstdc++ users.

My local RHEL 7.5 machines all pass the date check by accident. The date shows as 20150623.

llvm/trunk/CMakeLists.txt

else()
   option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON)
 endif()
 
 option(LLVM_ENABLE_EXPENSIVE_CHECKS "Enable expensive checks" OFF)
 
 set(LLVM_ABI_BREAKING_CHECKS "WITH_ASSERTS" CACHE STRING
   "Enable abi-breaking checks.  Can be WITH_ASSERTS, FORCE_ON or FORCE_OFF.")
 
-option(LLVM_FORCE_USE_OLD_HOST_TOOLCHAIN
+option(LLVM_FORCE_USE_OLD_TOOLCHAIN
        "Set to ON to force using an old, unsupported host toolchain." OFF)
 
+option(LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN
+       "Set to ON to only warn when using a toolchain which is about to be deprecated, instead of emitting an error." OFF)
+
 option(LLVM_USE_INTEL_JITEVENTS
   "Use Intel JIT API to inform Intel(R) VTune(TM) Amplifier XE 2011 about JIT code"
   OFF)
 
 if( LLVM_USE_INTEL_JITEVENTS )
   # Verify we are on a supported platform
   if( NOT CMAKE_SYSTEM_NAME MATCHES "Windows" AND NOT CMAKE_SYSTEM_NAME MATCHES "Linux" )
     message(FATAL_ERROR

llvm/trunk/cmake/modules/CheckCompilerVersion.cmake

 # Check if the host compiler is new enough.
 # These versions are updated based on the following policy:
 #   llvm.org/docs/DeveloperPolicy.html#toolchain
 
 include(CheckCXXSourceCompiles)
 
 set(GCC_MIN 4.8)
-set(GCC_WARN 4.8)
+set(GCC_SOFT_ERROR 5.1)
 set(CLANG_MIN 3.1)
-set(CLANG_WARN 3.1)
+set(CLANG_SOFT_ERROR 3.5)
 set(APPLECLANG_MIN 3.1)
-set(APPLECLANG_WARN 3.1)
-set(MSVC_MIN 19.0)
-set(MSVC_WARN 19.00.24213.1)
+set(APPLECLANG_SOFT_ERROR 6.0)
+set(MSVC_MIN 19.00.24213.1)
+set(MSVC_SOFT_ERROR 19.1)
+
+# Map the above GCC versions to dates: https://gcc.gnu.org/develop.html#timeline
+set(GCC_MIN_DATE 20130322)
+set(GCC_SOFT_ERROR_DATE 20150422)
+
 
 if(DEFINED LLVM_COMPILER_CHECKED)
   return()
 endif()
 set(LLVM_COMPILER_CHECKED ON)
 
 if(LLVM_FORCE_USE_OLD_TOOLCHAIN)
   return()
 endif()
 
-function(check_compiler_version NAME NICE_NAME MINIMUM_VERSION WARN_VERSION)
+function(check_compiler_version NAME NICE_NAME MINIMUM_VERSION SOFT_ERROR_VERSION)
   if(NOT CMAKE_CXX_COMPILER_ID STREQUAL NAME)
     return()
   endif()
   if(CMAKE_CXX_COMPILER_VERSION VERSION_LESS MINIMUM_VERSION)
     message(FATAL_ERROR "Host ${NICE_NAME} version must be at least ${MINIMUM_VERSION}, your version is ${CMAKE_CXX_COMPILER_VERSION}.")
-  elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS WARN_VERSION)
-    message(WARNING "Host ${NICE_NAME} version must be at least ${WARN_VERSION} due to miscompiles from earlier versions, your version is ${CMAKE_CXX_COMPILER_VERSION}.")
+  elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS SOFT_ERROR_VERSION)
+    if(LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN)
+      message(WARNING "Host ${NICE_NAME} version should be at least ${SOFT_ERROR_VERSION} because LLVM will soon use new C++ features which your toolchain version doesn't support. Your version is ${CMAKE_CXX_COMPILER_VERSION}. Ignoring because you've set LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't be supported.")
+    else()
+      message(FATAL_ERROR "Host ${NICE_NAME} version should be at least ${SOFT_ERROR_VERSION} because LLVM will soon use new C++ features which your toolchain version doesn't support. Your version is ${CMAKE_CXX_COMPILER_VERSION}. You can temporarily opt out using LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't be supported.")
+    endif()
   endif()
 endfunction(check_compiler_version)
 
-check_compiler_version("GNU" "GCC" ${GCC_MIN} ${GCC_WARN})
-check_compiler_version("Clang" "Clang" ${CLANG_MIN} ${CLANG_WARN})
-check_compiler_version("AppleClang" "Apple Clang" ${APPLECLANG_MIN} ${APPLECLANG_WARN})
-check_compiler_version("MSVC" "Visual Studio" ${MSVC_MIN} ${MSVC_WARN})
+check_compiler_version("GNU" "GCC" ${GCC_MIN} ${GCC_SOFT_ERROR})
+check_compiler_version("Clang" "Clang" ${CLANG_MIN} ${CLANG_SOFT_ERROR})
+check_compiler_version("AppleClang" "Apple Clang" ${APPLECLANG_MIN} ${APPLECLANG_SOFT_ERROR})
+check_compiler_version("MSVC" "Visual Studio" ${MSVC_MIN} ${MSVC_SOFT_ERROR})
 
 if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
   if (CMAKE_CXX_SIMULATE_ID MATCHES "MSVC")
     if (CMAKE_CXX_SIMULATE_VERSION VERSION_LESS MSVC_MIN)
       message(FATAL_ERROR "Host Clang must have at least -fms-compatibility-version=${MSVC_MIN}, your version is ${CMAKE_CXX_COMPILER_VERSION}.")
     endif()
     set(CLANG_CL 1)
   elseif(NOT LLVM_ENABLE_LIBCXX)
-    # Test that we aren't using too old of a version of libstdc++
-    # with the Clang compiler. This is tricky as there is no real way to
-    # check the version of libstdc++ directly. Instead we test for a known
-    # bug in libstdc++4.6 that is fixed in libstdc++4.7.
+    # Test that we aren't using too old of a version of libstdc++.
     set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
     set(OLD_CMAKE_REQUIRED_LIBRARIES ${CMAKE_REQUIRED_LIBRARIES})
     set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++0x")
     check_cxx_source_compiles("
-#include <atomic>
-std::atomic<float> x(0.0f);
-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!")
+#include <iosfwd>
+#if defined(__GLIBCXX__)
+#if __GLIBCXX__ < ${GCC_MIN_DATE}
+#error Unsupported libstdc++ version
+#endif
+#endif
+int main() { return 0; }
+"
+      LLVM_LIBSTDCXX_MIN)
+    if(NOT LLVM_LIBSTDCXX_MIN)
+      message(FATAL_ERROR "libstdc++ version must be at least ${GCC_MIN}.")
+    endif()
+    check_cxx_source_compiles("
+#include <iosfwd>
+#if defined(__GLIBCXX__)
+#if __GLIBCXX__ < ${GCC_SOFT_ERROR_DATE}
+#error Unsupported libstdc++ version
+#endif
+#endif
+int main() { return 0; }
+"
+      LLVM_LIBSTDCXX_SOFT_ERROR)
+    if(NOT LLVM_LIBSTDCXX_SOFT_ERROR)
+      if(LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN)
+        message(WARNING "libstdc++ version should be at least ${GCC_SOFT_ERROR} because LLVM will soon use new C++ features which your toolchain version doesn't support. Ignoring because you've set LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't be supported.")
+      else()
+        message(FATAL_ERROR "libstdc++ version should be at least ${GCC_SOFT_ERROR} because LLVM will soon use new C++ features which your toolchain version doesn't support. You can temporarily opt out using LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN, but very soon your toolchain won't be supported.")
+      endif()
     endif()
     set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
     set(CMAKE_REQUIRED_LIBRARIES ${OLD_CMAKE_REQUIRED_LIBRARIES})
   endif()
 endif()

llvm/trunk/docs/CMake.rst

**LLVM_CCACHE_BUILD**:BOOL
   options, which are passed to the CCACHE_MAXSIZE and CCACHE_DIR environment
   variables, respectively.
 
 **LLVM_FORCE_USE_OLD_TOOLCHAIN**:BOOL
   If enabled, the compiler and standard library versions won't be checked. LLVM
   may not compile at all, or might fail at runtime due to known bugs in these
   toolchains.
 
+**LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN**:BOOL
+  If enabled, the compiler version check will only warn when using a toolchain
+  which is about to be deprecated, instead of emitting an error.
+
 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.
 

llvm/trunk/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 <http://gcc.gnu.org/>`_                                >=5.1.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

 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.
 
 LLVM is written using the subset of C++ documented in :doc:`coding
 standards<CodingStandards>`. To enforce this language version, we check the most
 popular host toolchains for specific minimum versions in our build systems:
 
+* Clang 3.5
+* Apple Clang 6.0
+* GCC 5.1
+* Visual Studio 2017
+
+The below versions currently soft-error as we transition to the new compiler
+versions listed above. The LLVM codebase is currently known to compile correctly
+with the following compilers, though this will change in the near future:
+
 * Clang 3.1
 * Apple Clang 3.1
 * GCC 4.8
 * Visual Studio 2015 (Update 3)
 
 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

 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.1.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
+  % gcc_version=5.1.0
+  % wget https://ftp.gnu.org/gnu/gcc/gcc-${gcc_version}/gcc-${gcc_version}.tar.bz2
+  % wget https://ftp.gnu.org/gnu/gcc/gcc-${gcc_version}/gcc-${gcc_version}.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-${gcc_version}.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-${gcc_version}.tar.bz2
+  % cd gcc-${gcc_version}
   % ./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-${gcc_version}-build
+  % cd gcc-${gcc_version}-build
+  % $PWD/../gcc-${gcc_version}/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: