<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 May 10, 2018, at 11:35 AM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">If it's the only thing we can agree then I'll take it, but I just worry that 3 years from now we're going to start another 3 year discussion, so that any actual move to C++17 would end up taking double the time.</div></div></blockquote><div><br class=""></div><div>Such a fatalistic view, let’s trust ourselves to be better next time ;-)</div><div>But seriously: we can learn from moving to C++14, and use what we’ve learned to move to C++17 faster next time. Also consider the code churn we’ll encounter as we fix incompatibilities with C++11 / C++14, drop unnecessary code, upgrade various uses, that will happen regardless of moving to C++17 and will take a little while to occur. There would be more of that type of churn if we went straight to C++17.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Are the issues specific to C++17 additions to the standard library? What if you allow C++17 language features but not C++17 library features? I'm guessing this is too simple though and isn't sufficient to avoid the problems (which I don't know anything about, so you'll have to enlighten me)?</div></div></div></blockquote><div><br class=""></div><div>Mostly library so far, yes, but the GCC 6 support for C++17 language isn’t great either:</div><div><br class=""></div><div><div class=""> - New auto rules for direct-list-initialization<span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""> - static_assert with no message</div><div class=""> - typename in a template template parameter</div><div class=""> - Nested namespace definition</div><div class=""> - Attributes for namespaces and enumerators</div><div class=""> - u8 character literals</div><div class=""> - Allow constant evaluation for all non-type template arguments</div><div class=""> - Fold Expressions</div><div class=""> - Unary fold expressions and empty parameter packs</div><div class=""> - __has_include in preprocessor conditional</div><div class=""> - Differing begin and end types in range-based for\</div></div><div><br class=""></div><div>From: <a href="https://en.cppreference.com/w/cpp/compiler_support" class="">https://en.cppreference.com/w/cpp/compiler_support</a></div><div><br class=""></div><div>The only thing that’s really nice are fold expressions, and I hope they’re not buggy in GCC 6.</div><div><br class=""></div><div>Otherwise the list is missing a good amount for C++17 language features, and brings up the discussion of which GCC version is the minimum we mandate. I’d rather avoid that discussion. Let’s assume GCC 6, if we get 7 then great, but it doesn’t matter if we stick to C++14.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, May 10, 2018 at 11:28 AM JF Bastien <<a href="mailto:jfbastien@apple.com" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 10, 2018, at 11:22 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank" class="">zturner@google.com</a>> wrote:</div><br class="m_-9000651513865904317Apple-interchange-newline"><div class=""><div dir="ltr" class="">Windows has never been the issue. Honestly, MSVC on Windows is "fully C++17 conformant" [1].<div class=""><br class=""></div><div class="">The issue has and always will be GCC. Given that a bump in any version of GCC has been (and will remain) difficult for some time, I propose that we skip C++14 and move to 17. We don't want to have a multi-year disccusion about this again any time soon, and from what I gather, nobody has any more reservations about moving to C++17 than they do about moving to C++14. They only have reservations about moving to anything at all. So if we're gonna move, we should go all the way.</div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="">WebKit’s move to C++17 hasn’t been super smooth because of GCC / libstdc++ issues in both GCC 6 and GCC 7. It’s all fixable, but given LLVM's slow move out of C++11 I’d rather get C++14 now rather than a painful transition to C++17 that drags on as we discover issues.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Just my 2c.<br class=""><div class=""><br class=""></div><div class="">[1] <a href="https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/" target="_blank" class="">https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/</a></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, May 10, 2018 at 11:18 AM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" class="">echristo@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Once again, I'm totally down for this and think we should do it. I worry about windows, but ...<div class=""><br class=""></div><div class="">Zach: How's windows c++14 support looking?</div></div><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-eric</div></div><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, May 10, 2018 at 10:01 AM JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Hi folks!</div><div class=""><br class=""></div><div class="">Six more months have come and gone, and maybe we could move LLVM to C++14 now?</div><div class=""><br class=""></div><div class="">The issues I picked out from the last discussion:</div><div class=""><ol class=""><li class="">Some folks want an official policy about compiler support before updating the standard version we use.</li><li class="">Worries about which GCC version is available in which distro.</li><li class="">Worries about MSVC.</li></ol></div><div class=""><br class=""></div><div class="">Instead of rehashing the compiler per distro surveys from previous discussion, and instead of talking bootstrap, let me offer three data points:</div><div class=""><ul class=""><li class="">WebKit is <a href="https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html" target="_blank" class="">moving to C++17</a> (from C++14) right now †</li><li class="">Chromium <a href="https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ" target="_blank" class="">started moving to C++14</a> in August of last year</li><li class="">Firefox uses <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code" target="_blank" class="">some C++14</a></li></ul></div><div class="">What I get from this data: if your distro bundles a modern web browser, it already builds some C++14, <i class="">somehow</i>.</div><div class=""><br class=""></div><div class="">The LLVM community has been talking about this for a while now, and I’m not aware of a policy coming to light. I don’t think we need a policy given the above data. So how about we… just kinda... move LLVM to C++14?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">JF</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">† the move to C++17 is very painful, but 14 has been working great in WebKit for quite a long time.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">> Last time we discussed this, the consensus was "I think we can survive</div><div class="">> another year without generalized constexpr and variable templates".</div><div class="">> </div><div class="">> Well, we did indeed survive. And it's been exactly a year! So naturally,</div><div class="">> it only makes sense to revive this :)</div><div class="">> </div><div class="">> </div><div class="">> </div><div class="">> There's an active conversation going on in IRC right now, and it seems like</div><div class="">> there is more desire than there was last year.</div><div class="">> </div><div class="">> What are the main gains from allowing C++14?</div><div class="">> * Variable templates</div><div class="">> * Generalized constexpr</div><div class="">> * Return-type Deduction</div><div class="">> * Generic Lambdas</div><div class="">> * std::make_unique<> (the source of many build bot breakages)</div><div class="">> </div><div class="">> </div><div class="">> What are the main gains from allowing C++17? [1]</div><div class="">> * [[nodiscard]] attribute</div><div class="">> * structured bindings</div><div class="">> * constexpr-if</div><div class="">> * guaranteed copy elision</div><div class="">> * numerous new library types: optional, string_view, variant, byte,</div><div class="">> * numerous new algorithms: parallel algorithms, too many to list</div><div class="">> * Probably some more, but I just tried to hit the biggest ones.</div><div class="">> </div><div class="">> </div><div class="">> First, it seems like if we want to enable C++14 we need GCC >= 5.</div><div class="">> And if we want to enable C++17 we need GCC >= 7.</div><div class="">> </div><div class="">> With that out of the way, here were some of the issues that were raised</div><div class="">> last time:</div><div class="">> </div><div class="">> Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and we have to support it until</div><div class="">> end of life.</div><div class="">> Resolution: LTS is right around the corner, in 6 more months.</div><div class="">> </div><div class="">> Issue: Various other platforms have older GCCs as their system compiler,</div><div class="">> and it's annoying to upgrade.</div><div class="">> Question: Do any of these not have a port you can install? For example,</div><div class="">> NetBSD 7 appears to have GCC 5.3 as a port, if DistroWatch is any</div><div class="">> indication. It could be wrong though and I could also be misinterpreting</div><div class="">> it.</div><div class="">> </div><div class="">> Issue: If we're going to make people bootstrap a compiler, we might as well</div><div class="">> go all the way to C++17.</div><div class="">> Comment: I'm not opposed.</div><div class="">> </div><div class="">> </div><div class="">> Some questions / comments of my own:</div><div class="">> </div><div class="">> * Where is this policy about Ubuntu and LTS documented? Does this mean,</div><div class="">> for example, that we will not be able to use C++17 until 2023 (16.04 LTS</div><div class="">> has only GCC 5.3.1)? That seems a bit unreasonable. And there's no</div><div class="">> guarantee that 18.04 LTS will even have GCC 7 or higher either, so it could</div><div class="">> be 2025 or 2027.</div><div class="">> </div><div class="">> * We've asked people in the past to build a modern toolchain. For example,</div><div class="">> we did it with C++11 and Ubuntu 12.04 LTS. Is C++17 compelling enough to</div><div class="">> justify this again?</div><div class="">> </div><div class="">> * GCC 4.9 probably isn't sufficient to justify an increase for anyone, as</div><div class="">> it lacks two of the more sought-after features of C++14 (variable templates</div><div class="">> and generalized constexpr). So IMO we should require a bump to GCC 5 or</div><div class="">> higher, or not at all.</div><div class="">> </div><div class="">> * Clang 6 supports all of C++20, and it builds with only C++11, so we</div><div class="">> shouldn't have to worry too much about the problem of needing to "daisy</div><div class="">> chain" compilers to finally get the latest version of LLVM building. "GCC</div><div class="">> 4.8 -> Clang 6 - > Clang ToT" should hold up through C++1z.</div><div class="">> </div><div class="">> * While we obviously can't be tied to the versioning of every single distro</div><div class="">> out there, some are "bigger" than others. Which are big enough that</div><div class="">> warrant serious consideration? The ones I found are (and I did my best to</div><div class="">> aggregate all this, but please correct me if anything is incorrect or</div><div class="">> misrepresented):</div><div class="">> </div><div class="">> OpenBSD - Ships with GCC 4.2.1 anyway. They are already having to</div><div class="">> bootstrap something, so the proposal here does not change anything, because</div><div class="">> even current LLVM doesn't compile with GCC 4.2.1</div><div class="">> </div><div class="">> CentOS & RHEL - No version of Distro, including trunk, has GCC >= 4.8.5</div><div class="">> (are there ports?)</div><div class="">> </div><div class="">> Debian - Minimum version 9 for GCC >= 5 (are there ports for earlier</div><div class="">> releases?)</div><div class="">> </div><div class="">> Fedora - Minimum version 24 for GCC >= 5, minimum version 26 for GCC >= 7</div><div class="">> </div><div class="">> Ubuntu - Minimum LTS 16.04 for GCC >= 5</div><div class="">> </div><div class="">> NetBSD - Version 7 has GCC 4.8.4 by default, but contains port for 5.3.0</div><div class="">> </div><div class="">> FreeBSD - Minimum Version 11 for GCC >= 5</div><div class="">> </div><div class="">> So, thoughts?</div><div class="">> </div><div class="">> </div><div class="">> [1] - Note that we'd need to wait a few more revs for MSVC before allowing</div><div class="">> C++17, but given that it's becoming easier and easier to bump the minimum</div><div class="">> MSVC version, I'm discounting this as a factor, as MSVC will not really be</div><div class="">> the bottleneck in any real sense.</div><div class="">> </div><div class="">> On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini <mehdi.amini at <a href="http://apple.com/" target="_blank" class="">apple.com</a>> wrote:</div><div class="">> </div><div class="">>></div><div class="">>> On Oct 4, 2016, at 2:10 PM, Reid Kleckner <rnk at <a href="http://google.com/" target="_blank" class="">google.com</a>> wrote:</div><div class="">>></div><div class="">>> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at <a href="http://apple.com/" target="_blank" class="">apple.com</a>></div><div class="">>> wrote:</div><div class="">>></div><div class="">>>></div><div class="">>>> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <</div><div class="">>>> llvm-dev at <a href="http://lists.llvm.org/" target="_blank" class="">lists.llvm.org</a>> wrote:</div><div class="">>>></div><div class="">>>> On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at <a href="http://google.com/" target="_blank" class="">google.com</a>></div><div class="">>>> wrote:</div><div class="">>>>></div><div class="">>>>> I ask because many of these LTS distros are notoriously slow at updating</div><div class="">>>>> their packages. While some people may think C++14 doesn't provide enough</div><div class="">>>>> bang for the buck to justify bumping to GCC 4.9, C++17 definitely does. But</div><div class="">>>>> at that point we're going to be talking about GCC 6.1 or 6.2, which is</div><div class="">>>>> going to be significantly harder unless we want to wait 5-7 years, and I</div><div class="">>>>> suspect people won't.</div><div class="">>>>></div><div class="">>>></div><div class="">>>> If by "notoriously slow" you mean they don't bump their toolchain</div><div class="">>>> versions at all, then yeah. We just wait until the LTS release is at</div><div class="">>>> end-of-life before dropping it.</div><div class="">>>></div><div class="">>>></div><div class="">>>> That’s the first time I read about this policy: we support every linux</div><div class="">>>> LTS distribution till their end-of-life? Only Ubuntu? Do you have a pointer</div><div class="">>>> where it is documented / discussed?</div><div class="">>>> (Note that Ubuntu LTS is 5 years AFAIK.)</div><div class="">>>></div><div class="">>></div><div class="">>> Sorry, I didn't mean to refer to the LTS support lifetime. I just meant we</div><div class="">>> support the last LTS until we can reasonably expect users to have upgraded</div><div class="">>> to the new one. If there's an LTS release every two years, then we want to</div><div class="">>> keep supporting them for at least three years to give people a year to</div><div class="">>> upgrade.</div><div class="">>></div><div class="">>></div><div class="">>> OK, got it.</div><div class="">>></div><div class="">>> Thanks for clarifying!</div><div class="">>></div><div class="">>> Mehdi</div><div class="">>></div><div class="">>></div></div></div>_______________________________________________<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></blockquote></div>
</div></blockquote></div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>