<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2/10/20 4:28 PM, Johannes Doerfert
      via Openmp-dev wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20200210222826.77pi7rv7brlmn6rw@JDX1">
      <pre class="moz-quote-pre" wrap="">On 02/10, Jonas Hahnfeld wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Am Samstag, den 08.02.2020, 12:44 -0600 schrieb Johannes Doerfert:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">More than a year ago [0,1] LLVM moved to C++14 as the minimal required
C++ versions.

Today we like to finally follow with the OpenMP subproject [2].

This RFC allows provides visibility for the proposed change and allows
people to voice their opinion. Please reply if you are in favor or not
with as much reasoning as possible (or needed).
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
I don't see the merit and remain skeptical. From the post cited above,
which features would you want to use in the OpenMP runtimes?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
For now `make_unique`, but I don't think the question is the right one
to ask. The question I would ask is:
  Why should we diverge from LLVM on this point? Is there real gain?

IMHO, the argument for keeping it at 11 is not as strong as my desire to
align the OpenMP subproject more with LLVM and modernize the code.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I agree. We have project-wide coding standards, compiler
      requirements, and so on. We should not diverge, in any subproject,
      without an explicitly-documented rationale.</p>
    <p> -Hal<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:20200210222826.77pi7rv7brlmn6rw@JDX1">
      <pre class="moz-quote-pre" wrap="">

TBH, I think if you already build your own OpenMP runtime you should be
capable of building a decent version of clang first. Clang 3.4 is needed
for C++14 and it can be build with C++11. We will hopefully soon have
scripts in tree to do the bootstrapping so it's easier to get an OpenMP
offload capable clang.

Cheers,
  Johannes

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">I'll mention a few reasons why the change is justified and good for us
below, the LLVM discussion has probably a similar section:

  - The OpenMP runtime is tied to the LLVM project, it should require a
    very good reason not to follow the coding rules, standards, best
    practices, minimal versions, ... of the LLVM project.
  - It is 2020, LLVM requires C++14 for a year, it seems people are able
    to find an C++14 enabled compiler. In the *worst case* it requires
    people that *only* want to build the *newest* OpenMP runtime to
    bootstrap, or download, an older Clang release.
  - We are not compatible with LLVM-core, thus we cannot reuse, in any
    way, core code that uses C++14 features. The reuse discussion came
    up multiple times recently and there is good reason we will actually
    go down that road soon.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
Hmm, so you propose creating a dependency from the OpenMP runtime to
the LLVM libraries? Which classes would you want to use, probably some
of the ADTs? Does any of the other runtime libraries (libc++,
libc++abi, compiler-rt, sanitizers) already do this? IIRC libc++abi and
LLVMSupport share some demangling code, but that is manually copied.

Adopting this will make it very hard to use the LLVM OpenMP runtime
with other compilers.

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">  - We limit the code we can write which limits productivity and even
    shows in code reviews [3]. It starts at features like `make_unique`
    [3] but there are other features we will be able to use in the
    runtime over time.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
I fail to see how not being able to use make_unique limits
productivity, its definition in std:: doesn't provide new functionality
IMO (you can create unique_ptrs without it). Are there other concrete
features that you want to use?

Jonas

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Now one can say that HPC systems, or other old systems for that matter,
have old compilers but want to use the new runtimes. We do explicitly
support this use case now and in the future, with the caveat that the
new runtimes require a moderately modern compiler to be build from
scratch. This might be an inconvenience but I don't see it as a deal
breaker for users. On the other hand, I expect modernization to help
us in the long run with development and maintenance as it helped other
parts of the project.

Thanks for reading,
  Johannes


[0] 
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D66195">https://reviews.llvm.org/D66195</a>

[1] 
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html">http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html</a>

[2] 
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D74258">https://reviews.llvm.org/D74258</a>

[3] 
<a class="moz-txt-link-freetext" href="https://reviews.llvm.org/D74145">https://reviews.llvm.org/D74145</a>


</pre>
        </blockquote>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">


</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Openmp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openmp-dev@lists.llvm.org">Openmp-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </body>
</html>