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.
Keane, Erich via llvm-dev
2018-May-23 13:21 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
Hi all- I just wanted to bump this again, I know I sent it out on a Friday :) I realize this is a minor code change with significant implications, so it seems to me that I should ensure it gets extensive exposure. See the review here: https://reviews.llvm.org/D47073 -Erich -----Original Message----- From: Keane, Erich Sent: Friday, May 18, 2018 8:26 AM To: llvm-dev at lists.llvm.org Subject: RE: [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.
JF Bastien via llvm-dev
2019-Jan-08 00:45 UTC
[llvm-dev] A Short Policy Proposal Regarding Host Compilers
I’d like us to move forward with something along the lines Erich proposed back in May, ideally early enough in the LLVM 8 release process that people testing the release will be able to provide feedback. Are there any remaining concerns?> On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all- > I just wanted to bump this again, I know I sent it out on a Friday :) I realize this is a minor code change with significant implications, so it seems to me that I should ensure it gets extensive exposure. > See the review here: https://reviews.llvm.org/D47073 > -Erich > > -----Original Message----- > From: Keane, Erich > Sent: Friday, May 18, 2018 8:26 AM > To: llvm-dev at lists.llvm.org > Subject: RE: [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.8 > > Historically 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. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev