<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" class="">joker.eph@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I'm a bit puzzled as of why would a fix period of time be the best option to automatically cut support for older compilers?</div><div class=""><br class=""></div><div class="">Historically I believe we've been looking at a combination of:</div><div class=""><br class=""></div><div class="">1) What new feature we gain by dropping support for a given version of the compiler</div><div class="">2) What major OS out there have available (possibly through PPA?).</div><div class=""><br class=""></div><div class="">And balance the two aspects.</div><div class=""><br class=""></div><div class="">What is the motivation for changing this approach?</div></div></div></blockquote><div><br class=""></div><div>Historically we’ve been on C++11, minus some stuff. The motivation to change the approach is to not be stuck on older C++ versions.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">-- </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jan 7, 2019 at 4:46 PM JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br class="">
<br class="">
Are there any remaining concerns?<br class="">
<br class="">
<br class="">
> On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> <br class="">
> Hi all-<br class="">
> 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. <br class="">
> See the review here: <a href="https://reviews.llvm.org/D47073" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D47073</a><br class="">
> -Erich<br class="">
> <br class="">
> -----Original Message-----<br class="">
> From: Keane, Erich <br class="">
> Sent: Friday, May 18, 2018 8:26 AM<br class="">
> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> Subject: RE: [llvm-dev] A Short Policy Proposal Regarding Host Compilers<br class="">
> <br class="">
> I've heard just about zero opposition to this, so I've put a code review together here: <a href="https://reviews.llvm.org/D47073" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D47073</a> With the intent of either implementing this policy change, or encouraging further discussion/bikeshed.<br class="">
> <br class="">
> Thanks all!<br class="">
> -Erich<br class="">
> <br class="">
> -----Original Message-----<br class="">
> From: Brooks Davis [mailto:<a href="mailto:brooks@freebsd.org" target="_blank" class="">brooks@freebsd.org</a>]<br class="">
> Sent: Sunday, May 13, 2018 10:34 AM<br class="">
> To: Keane, Erich <<a href="mailto:erich.keane@intel.com" target="_blank" class="">erich.keane@intel.com</a>><br class="">
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers<br class="">
> <br class="">
> On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote:<br class="">
>> Hi All-<br class="">
>> 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:<br class="">
>> <br class="">
>> 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 <a href="https://reviews.llvm.org/D46723" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D46723</a>). 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). <br class="">
>> <br class="">
>> The 3-years/1.5 years would result in our minimum GCC/Clang becoming: <br class="">
>> GCC5.1/Clang3.6. We would WARN on anything older than GCC7.1/Clang3.8<br class="">
> <br class="">
> 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).<br class="">
> <br class="">
> -- Brooks<br class="">
> <br class="">
> [0] Some of them purely external due to a lack of viable LLVM support and a policy against GPLv3 licenses in the tree.<br class="">
> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div></div>
</div></blockquote></div><br class=""></body></html>