<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Minor note on process for these types
of discussions....<br>
<br>
When proposing we move to a new language version, it would be very
helpful if you could take the time to identify the specific
minimal compiler version required and the minimal distro version
which supports that toolchain for each of the major distros. For
those of us which ship software using LLVM, that's the mapping we
really need to decide whether a proposed upgrade is an issue or
not. <br>
<br>
For instance, I can probably upgrade to any compiler easily
buildable on REHL6, but likely *can not* upgrade to any compile
not buildable on REHL6. <br>
<br>
Having this up front saves a lot of research and makes the
discussion a lot easier internally. <br>
<br>
Thanks.<br>
<br>
Philip<br>
<br>
On 05/10/2018 10:01 AM, JF Bastien via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:EA906D45-0062-463D-87D0-2C5B1BB3344A@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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"
class="" moz-do-not-send="true">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"
class="" moz-do-not-send="true">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"
class="" moz-do-not-send="true">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" class=""
moz-do-not-send="true">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" class=""
moz-do-not-send="true">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" class=""
moz-do-not-send="true">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" class="" moz-do-not-send="true">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"
class="" moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>