[llvm-dev] A Short Policy Proposal Regarding Host Compilers

Sat May 12 20:55:31 PDT 2018

I want to chime in with an alternate perspective.  Not a counter 
argument per se, but something to consider.

When we first started evaluating LLVM, we were stuck with an absolutely 
ancient version of gcc.  We could use a newer compiler for LLVM, but if 
there was an ABI breakage - like the one moving to C++11 - between our 
build compiler and our choice of compiler for LLVM, we were pretty much 
dead in the water.  I honestly don't know if we'd had a problem at the 
time, that we'd have ever moved past it.  Or to say it differently, our 
initial evaluation period had a fixed number of person months 
allocated.  If we'd spent those person months fighting build systems, 
it's very likely we'd have not reached a point sufficient to justify a 
"go" on the rest of the project.

Just to highlight, the primary issue to be concerned about is ABI 
compatibility between whatever version of the compiler is required to 
build LLVM and the "build compiler" used for everything else. Having the 
compiler itself out of sync is (usually) not an issue, but having an ABI 
break - intentional or otherwise - is a show stopper.

Philip

On 05/11/2018 09:54 AM, Daniel Berlin via llvm-dev wrote:
> I'd be opposed to 6/5, given where it would leave us.
> It's simply hard to see a compelling reason to leave things that long.
>
> In particular, given this is about what it takes to produce a binary 
> release of clang/llvm from trunk (and not what it takes to use one), 
> i'd like to see some evidence/argument that using 3/1.5 would actually 
> have a material affect on the number of contributions, etc.
> (I have doubts it would have any affect on the abliity of new 
> developers to start contributing, etc).
> All of the clang/llvm based tools i have around (cquery, rtags, you 
> name it) all download and ship binary releases of clang/llvm (and 
> FWIW, they ship and use 1-2 year old releases).
> It's also unclear to me it makes sense to try to make sure any user 
> can compile the latest version - for example, researchers using it 
> almost never keep up with trunk, even with our current policy that 
> supports things for longer.  They stick with the version that existed 
> when they started.
> So it's unclear that we are doing a thing users actually want in 
> practice anyway :)
>
> Finally,  given the rate of support for newer C++ standards in 
> LLVM/GCC seems to be accelerating and not slowing down (AFAICT), 
> keeping a time period this long will just put you farther and farther 
> behind over time.
>
> It may be better to simply express it in terms of releases, and say 
> "we support the past 2/3 major gcc releases, the past 2/3 major clang 
> releases, and the past 2 major msvc releases"
>
>
>
>
>
> On Fri, May 11, 2018 at 8:58 AM, Andrew Kelley via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.
>
>     On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>         Hi All-
>         As we all know, the C++14 discussion is flaring up again. 
>         Chandler brought up that he would like a concrete plan to
>         switch.  In my opinion, this is insufficient, as it will
>         result in us simply having this discussion AGAIN next release.
>         Instead, I would prefer us to have a concrete Policy on our
>         host compilers.  That way, changes like this are unsurprising
>         to our users, and advance our codebase sufficiently.  I
>         believe the arguments for/against upgrading have been made
>         repeatedly, so I won't repeat them here.  My proposal is thus:
>
>         Starting with the Clang 7.0 release, we will officially
>         support any major release of our host compilers (MSVC, GCC,
>         Clang, ?ICC?) released in the past 3* years from our previous
>         branch date to give trunk-developers time to transition (so
>         for 7.0, 3 years before January 3, 2018).  This will be
>         enforced via the CMake CheckCompilerVersion script (ala
>         https://reviews.llvm.org/D46723
>         <https://reviews.llvm.org/D46723>). ADDITIONALLY, a CMake
>         warning will be issued for any major release less than 1.5*
>         years old to give our users sufficient time to
>         transition/upgrade their compilers.  Finally, our dependent
>         C++ version will be the best released standard officially
>         supported by the collection of compilers (for example, we'd
>         support -C++20 if all compilers had std=c++20 or eqiv, but NOT
>         std=c++2a).
>
>         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
>
>         /End Proposal
>
>
>         *: To Be Bikeshed
>         _______________________________________________
>         LLVM Developers mailing list
>         llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180512/eea2c9a8/attachment.html>