<div dir="ltr">The Red Hat Developer Toolset supports gcc 7 on RHEL 6.7 or later. The builds it produces are ABI compatible with the rest of the system. This does mean the library is not 100% conformant, using for example, the old COW string rather than SSO. <div><br><div><div class="gmail_quote"><div dir="ltr"><div dir="ltr">Some detail: <a href="https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/user_guide/chap-red_hat_developer_toolset#sect-Red_Hat_Developer_Toolset-Compatibility">https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/user_guide/chap-red_hat_developer_toolset#sect-Red_Hat_Developer_Toolset-Compatibility</a></div><div dir="ltr"><br></div><br>On Sun, May 13, 2018 at 12:52 AM Bruce Hoult via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:large">As you probably know, RHEL6 comes with gcc 4.4.7, which doesn't even support C++11. You can install gcc 6.3.1 from Red Hat Software Collections, and that fully supports C++11 and C++14, but not 17.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 13, 2018 at 3:43 PM, Philip Reames via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_5053646829379744771m_-2784194842763130854moz-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<div><div class="m_5053646829379744771h5"><br>
      <br>
      On 05/10/2018 10:01 AM, JF Bastien via llvm-dev wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="m_5053646829379744771h5">
      
      <div>Hi folks!</div>
      <div><br>
      </div>
      <div>Six more months have come and gone, and maybe we
        could move LLVM to C++14 now?</div>
      <div><br>
      </div>
      <div>The issues I picked out from the last discussion:</div>
      <div>
        <ol>
          <li>Some folks want an official policy about compiler
            support before updating the standard version we use.</li>
          <li>Worries about which GCC version is available in
            which distro.</li>
          <li>Worries about MSVC.</li>
        </ol>
      </div>
      <div><br>
      </div>
      <div>Instead of rehashing the compiler per distro surveys
        from previous discussion, and instead of talking bootstrap, let
        me offer three data points:</div>
      <div>
        <ul>
          <li>WebKit is <a href="https://lists.webkit.org/pipermail/webkit-dev/2018-March/029922.html" target="_blank">moving to C++17</a> (from
            C++14) right now †</li>
          <li>Chromium <a href="https://groups.google.com/a/chromium.org/d/msg/cxx/ow7hmdDm4yw/eV6KWL2yAQAJ" target="_blank">started moving to C++14</a> in
            August of last year</li>
          <li>Firefox uses <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code" target="_blank">some C++14</a></li>
        </ul>
      </div>
      <div>What I get from this data: if your distro bundles a
        modern web browser, it already builds some C++14, <i>somehow</i>.</div>
      <div><br>
      </div>
      <div>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><br>
      </div>
      <div><br>
      </div>
      <div>Thanks!</div>
      <div><br>
      </div>
      <div>JF</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>† the move to C++17 is very painful, but 14 has been
        working great in WebKit for quite a long time.</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>
        <div>> Last time we discussed this, the consensus
          was "I think we can survive</div>
        <div>> another year without generalized constexpr
          and variable templates".</div>
        <div>> </div>
        <div>> Well, we did indeed survive.   And it's been
          exactly a year!  So naturally,</div>
        <div>> it only makes sense to revive this :)</div>
        <div>> </div>
        <div>> </div>
        <div>> </div>
        <div>> There's an active conversation going on in
          IRC right now, and it seems like</div>
        <div>> there is more desire than there was last
          year.</div>
        <div>> </div>
        <div>> What are the main gains from allowing C++14?</div>
        <div>> * Variable templates</div>
        <div>> * Generalized constexpr</div>
        <div>> * Return-type Deduction</div>
        <div>> * Generic Lambdas</div>
        <div>> * std::make_unique<> (the source of
          many build bot breakages)</div>
        <div>> </div>
        <div>> </div>
        <div>> What are the main gains from allowing C++17?
           [1]</div>
        <div>> * [[nodiscard]] attribute</div>
        <div>> * structured bindings</div>
        <div>> * constexpr-if</div>
        <div>> * guaranteed copy elision</div>
        <div>> * numerous new library types: optional,
          string_view, variant, byte,</div>
        <div>> * numerous new algorithms: parallel
          algorithms, too many to list</div>
        <div>> * Probably some more, but I just tried to hit
          the biggest ones.</div>
        <div>> </div>
        <div>> </div>
        <div>> First, it seems like if we want to enable
          C++14 we need GCC >= 5.</div>
        <div>> And if we want to enable C++17 we need GCC
          >= 7.</div>
        <div>> </div>
        <div>> With that out of the way, here were some of
          the issues that were raised</div>
        <div>> last time:</div>
        <div>> </div>
        <div>> Issue: Ubuntu 14.04 LTS is on GCC 4.8.x, and
          we have to support it until</div>
        <div>> end of life.</div>
        <div>> Resolution: LTS is right around the corner,
          in 6 more months.</div>
        <div>> </div>
        <div>> Issue: Various other platforms have older
          GCCs as their system compiler,</div>
        <div>> and it's annoying to upgrade.</div>
        <div>> Question: Do any of these not have a port you
          can install?  For example,</div>
        <div>> NetBSD 7 appears to have GCC 5.3 as a port,
          if DistroWatch is any</div>
        <div>> indication.  It could be wrong though and I
          could also be misinterpreting</div>
        <div>> it.</div>
        <div>> </div>
        <div>> Issue: If we're going to make people
          bootstrap a compiler, we might as well</div>
        <div>> go all the way to C++17.</div>
        <div>> Comment: I'm not opposed.</div>
        <div>> </div>
        <div>> </div>
        <div>> Some questions / comments of my own:</div>
        <div>> </div>
        <div>> * Where is this policy about Ubuntu and LTS
          documented?  Does this mean,</div>
        <div>> for example, that we will not be able to use
          C++17 until 2023 (16.04 LTS</div>
        <div>> has only GCC 5.3.1)?  That seems a bit
          unreasonable.  And there's no</div>
        <div>> guarantee that 18.04 LTS will even have GCC 7
          or higher either, so it could</div>
        <div>> be 2025 or 2027.</div>
        <div>> </div>
        <div>> * We've asked people in the past to build a
          modern toolchain.  For example,</div>
        <div>> we did it with C++11 and Ubuntu 12.04 LTS.
           Is C++17 compelling enough to</div>
        <div>> justify this again?</div>
        <div>> </div>
        <div>> * GCC 4.9 probably isn't sufficient to
          justify an increase for anyone, as</div>
        <div>> it lacks two of the more sought-after
          features of C++14 (variable templates</div>
        <div>> and generalized constexpr).  So IMO we should
          require a bump to GCC 5 or</div>
        <div>> higher, or not at all.</div>
        <div>> </div>
        <div>> * Clang 6 supports all of C++20, and it
          builds with only C++11, so we</div>
        <div>> shouldn't have to worry too much about the
          problem of needing to "daisy</div>
        <div>> chain" compilers to finally get the latest
          version of LLVM building.  "GCC</div>
        <div>> 4.8 -> Clang 6 - > Clang ToT" should
          hold up through C++1z.</div>
        <div>> </div>
        <div>> * While we obviously can't be tied to the
          versioning of every single distro</div>
        <div>> out there, some are "bigger" than others.
           Which are big enough that</div>
        <div>> warrant serious consideration?  The ones I
          found are (and I did my best to</div>
        <div>> aggregate all this, but please correct me if
          anything is incorrect or</div>
        <div>> misrepresented):</div>
        <div>> </div>
        <div>> OpenBSD - Ships with GCC 4.2.1 anyway.  They
          are already having to</div>
        <div>> bootstrap something, so the proposal here
          does not change anything, because</div>
        <div>> even current LLVM doesn't compile with GCC
          4.2.1</div>
        <div>> </div>
        <div>> CentOS & RHEL - No version of Distro,
          including trunk, has GCC >= 4.8.5</div>
        <div>> (are there ports?)</div>
        <div>> </div>
        <div>> Debian - Minimum version 9 for GCC >= 5
           (are there ports for earlier</div>
        <div>> releases?)</div>
        <div>> </div>
        <div>> Fedora - Minimum version 24 for GCC >= 5,
          minimum version 26 for GCC >= 7</div>
        <div>> </div>
        <div>> Ubuntu - Minimum LTS 16.04 for GCC >= 5</div>
        <div>> </div>
        <div>> NetBSD - Version 7 has GCC 4.8.4 by default,
          but contains port for 5.3.0</div>
        <div>> </div>
        <div>> FreeBSD - Minimum Version 11 for GCC >= 5</div>
        <div>> </div>
        <div>> So, thoughts?</div>
        <div>> </div>
        <div>> </div>
        <div>> [1] - Note that we'd need to wait a few more
          revs for MSVC before allowing</div>
        <div>> C++17, but given that it's becoming easier
          and easier to bump the minimum</div>
        <div>> MSVC version, I'm discounting this as a
          factor, as MSVC will not really be</div>
        <div>> the bottleneck in any real sense.</div>
        <div>> </div>
        <div>> On Tue, Oct 4, 2016 at 2:15 PM Mehdi Amini
          <mehdi.amini at <a href="http://apple.com" target="_blank">apple.com</a>> wrote:</div>
        <div>> </div>
        <div>>></div>
        <div>>> On Oct 4, 2016, at 2:10 PM, Reid Kleckner
          <rnk at <a href="http://google.com" target="_blank">google.com</a>> wrote:</div>
        <div>>></div>
        <div>>> On Tue, Oct 4, 2016 at 11:58 AM, Mehdi
          Amini <mehdi.amini at <a href="http://apple.com" target="_blank">apple.com</a>></div>
        <div>>> wrote:</div>
        <div>>></div>
        <div>>>></div>
        <div>>>> On Oct 4, 2016, at 8:40 AM, Reid
          Kleckner via llvm-dev <</div>
        <div>>>> llvm-dev at <a href="http://lists.llvm.org" target="_blank">lists.llvm.org</a>>
          wrote:</div>
        <div>>>></div>
        <div>>>> On Tue, Oct 4, 2016 at 8:29 AM,
          Zachary Turner <zturner at <a href="http://google.com" target="_blank">google.com</a>></div>
        <div>>>> wrote:</div>
        <div>>>>></div>
        <div>>>>> I ask because many of these LTS
          distros are notoriously slow at updating</div>
        <div>>>>> their packages. While some people
          may think C++14 doesn't provide enough</div>
        <div>>>>> bang for the buck to justify
          bumping to GCC 4.9, C++17 definitely does. But</div>
        <div>>>>> at that point we're going to be
          talking about GCC 6.1 or 6.2, which is</div>
        <div>>>>> going to be significantly harder
          unless we want to wait 5-7 years, and I</div>
        <div>>>>> suspect people won't.</div>
        <div>>>>></div>
        <div>>>></div>
        <div>>>> If by "notoriously slow" you mean
          they don't bump their toolchain</div>
        <div>>>> versions at all, then yeah. We just
          wait until the LTS release is at</div>
        <div>>>> end-of-life before dropping it.</div>
        <div>>>></div>
        <div>>>></div>
        <div>>>> That’s the first time I read about
          this policy: we support every linux</div>
        <div>>>> LTS distribution till their
          end-of-life? Only Ubuntu? Do you have a pointer</div>
        <div>>>> where it is documented / discussed?</div>
        <div>>>> (Note that Ubuntu LTS is 5 years
          AFAIK.)</div>
        <div>>>></div>
        <div>>></div>
        <div>>> Sorry, I didn't mean to refer to the LTS
          support lifetime. I just meant we</div>
        <div>>> support the last LTS until we can
          reasonably expect users to have upgraded</div>
        <div>>> to the new one. If there's an LTS release
          every two years, then we want to</div>
        <div>>> keep supporting them for at least three
          years to give people a year to</div>
        <div>>> upgrade.</div>
        <div>>></div>
        <div>>></div>
        <div>>> OK, got it.</div>
        <div>>></div>
        <div>>> Thanks for clarifying!</div>
        <div>>></div>
        <div>>> Mehdi</div>
        <div>>></div>
        <div>>></div>
      </div>
      <br>
      <fieldset class="m_5053646829379744771m_-2784194842763130854mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><span><pre>_______________________________________________
LLVM Developers mailing list
<a class="m_5053646829379744771m_-2784194842763130854moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_5053646829379744771m_-2784194842763130854moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </span></blockquote>
    <p><br>
    </p>
  </div>

<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>