Keane, Erich via llvm-dev
2018-May-11 13:37 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
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). 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
Adrien Guinet via llvm-dev
2018-May-11 14:28 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
On 05/11/2018 03:37 PM, Keane, Erich via llvm-dev 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). 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 BikeshedOne thing to consider (and, as far as I understand, is one of the main issue) is that you can have an up-to-date compiler using an old C++ standard library. One example would be to install Clang 6 in Debian jessie (using i.e. http://apt.llvm.org/jessie/). libstdc++ is the one of GCC 4.9 in this system, and I think their would be issues in this case compiling C++14 code. The idea would be to also add checks for the version of the standard C++ library that is used to compile LLVM. It is maybe also possible to use an up-to-date libc++ and statically compile LLVM with it, but I've never tried it thought. -- Adrien.
Andrew Kelley via llvm-dev
2018-May-11 15:58 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
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> 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). 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 > 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/20180511/c7c29ef1/attachment.html>
Keane, Erich via llvm-dev
2018-May-11 16:04 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
Based on my reading of the release pages (https://gcc.gnu.org/releases.html and http://releases.llvm.org/) 6/5 would make GCC 4.7 and Clang 3.1 required, and GCC 4.8 and Clang 3.3 the first to not warn. 6/5 is surprisingly close to making the policy conform to exactly our current time-lag, where we are GCC4.8 (instead of 4.7) and Clang 3.1 (also 3.1). -Erich From: Andrew Kelley [mailto:superjoe30 at gmail.com] Sent: Friday, May 11, 2018 8:58 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers 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). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180511/352ef5d0/attachment.html>
Daniel Berlin via llvm-dev
2018-May-11 16:54 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
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> 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> 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). 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 >> 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/20180511/d26368a6/attachment.html>
Brooks Davis via llvm-dev
2018-May-13 17:33 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev 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). 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.8Historically 3/1.5 would have caused us problems on FreeBSD, but we're moving to supporting all architectures via an external toolchain[0] so I don't think it will have a major impact. We'll have to amend our statement of which systems you can bootstrap from to include the need to install a compiler package in some cases (or be more aggressive about merging new compiler versions to stable branches). -- Brooks [0] Some of them purely external due to a lack of viable LLVM support and a policy against GPLv3 licenses in the tree.
Keane, Erich via llvm-dev
2018-May-18 15:25 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
I've heard just about zero opposition to this, so I've put a code review together here: https://reviews.llvm.org/D47073 With the intent of either implementing this policy change, or encouraging further discussion/bikeshed. Thanks all! -Erich -----Original Message----- From: Brooks Davis [mailto:brooks at freebsd.org] Sent: Sunday, May 13, 2018 10:34 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev 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). 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.8Historically 3/1.5 would have caused us problems on FreeBSD, but we're moving to supporting all architectures via an external toolchain[0] so I don't think it will have a major impact. We'll have to amend our statement of which systems you can bootstrap from to include the need to install a compiler package in some cases (or be more aggressive about merging new compiler versions to stable branches). -- Brooks [0] Some of them purely external due to a lack of viable LLVM support and a policy against GPLv3 licenses in the tree.