[cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[Benjamin Kramer]

On 27.10.2013, at 10:23, Chandler Carruth <chandlerc at google.com> wrote:

> Greetings,
> 
> This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.
> 
> I am seriously concerned that if we don't do this now, we will miss out on the accelerating trend of C++ as a language.
> 
> Concrete long term proposal:
> 
> We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.
> 
> Some observations:
> - I specifically am wording this to enable the mainline to use features sooner. People who are unable to use an *even more* modern toolchain will necessarily stay with each release.
> - This is an aggressive timeline. That is intentional. There is increasing pressure for LLVM to make use of new C++ language and library features.
> - There is always the option of checking out an old release, building it, and then using that compiler to build the latest release or to build the mainline compiler.
> - The goal is to only change the supported toolchain set and thus C++ dialect after a release branches to avoid confusion, churn, and impeding QA on a release. People can check out trunk and get an idea of whether they will have problems with the next release.
> - I have historically been more conservative on this topic, but listening to many people and looking at some of the C++ features we are missing, I think the right strategy for the project is a more aggressive one.
> 
> 
> One short term caveat: Windows is special.
> 
> I don't think we should follow the 2-year rule for Windows. It really is special for at least three reasons:
> 1) We can't bootstrap on Windows. While there is tons of exciting work going on here to change that, even then the quality of Windows support is likely to change very rapidly.
> 2) Visual Studio's C++ support moved very slowly for a long time, and is now improving at an amazing rate. We shouldn't be hampered by past problems and should take advantage of this recent progress.
> 3) We have less insight into when new versions of the MSVC++ toolchain will arrive.
> 
> So my suggestion is that, at least during the rapid evolution of VS's C++11 support and Clang's Windows support, we support building with the most recent 2 versions of VS available at the *prior* release. For example when we branch for 3.4, the two versions will be 2012 and 2013. Those two would be supported on mainline from then through 3.5, and when we branch for 3.5 we would re-evaluate.
> 
> NOTE: This would drop support for VS 2010!!! That is a huge change, hence my suggesting it only *after* we branch for 3.4. It gives us an entire release cycle of notice for people relying on it.
> 
> 
> Now for the carrot: if we go with this plan, then immediately after branching for 3.4,  we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:
> 
> GCC 4.7
> Clang 3.1
> VS 2012

I do think that the time has come to switch to C++11 now as toolchains are becoming available everywhere. However, in my opinion a rule based on the releases of compilers won't work out for the majority of users out there. I'd rather base it on availability on operating systems, that's of course a fuzzy rule but it turns out that the number of common offenders shipping outdated toolchains is small.

My proposal is: look at the versions of OS's released in the last two years and check if they have shipped an outdated toolchain.

- Freebsd 10 is on Clang/libc++ by default, FreeBSD 9 also shipped Clang. Don't see problems here.
- Not sure about other BSD's, but I'd expect them to either follow FreeBSD or provide a newer GCC already.
- OS X is on Clang/libc++ by default now and has shipped Clang for a while. No issue here.
- Windows is special as people have to manage their own toolchain. However, we have aggressively dropped old MSVC versions in the past, I doubt dropping MSVC 2010 is a big problem as there's still 2012 and 2013 for people to pick from.

Then there's the long list of linux distros. I looked at those supported by Clang's toolchain config right now.
- Debian has (finally) switched to GCC 4.7. I don't think supporting old stable (Debian 6 is from 2011, GCC 4.4) really helps anyone.
- RHEL/CentOS is still on GCC 4.4 as far as I know. This is a problem if not solved within the next 6 months.
- SLES 11 was upgraded to GCC 4.7 in a service pack recently.
- Ubuntu is on GCC 4.7; LTS is on 4.6 but the next LTS release is likely out before LLVM 3.5 ships.
- The remaining distros have shorter release cycles (Arch, Exherbo, Fedora, OpenSUSE) and have migrated to a recent toolchain long ago.

So the only real problem is RHEL and its derivatives. Does anyone know if there's a new release imminent or an easy way to get a new toolchain on an existing installation?

- Ben

> 
> Some notable features we would get to use:
> 
> - r-value references, move semantics, etc
> - auto
> - range for loops
> - lambdas
> - static_assert
> - nullptr
> - std::unique_ptr, std::tuple, some other nice library stuff
> 
> 
> These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.
> 
> -Chandler
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev