[Openmp-dev] [RFC] Requiring C++14 for the OpenMP subproject

Johannes Doerfert via Openmp-dev openmp-dev at lists.llvm.org
Tue Feb 11 09:26:51 PST 2020


For the record, we'll go ahead with the C++14 requirement. We'll revisit
the other points listed below, e.g., code sharing/dependences, as they
come up and probably in a bigger setting (llvm-dev).

Cheers,
  Johannes

On 02/08, Johannes Doerfert via Openmp-dev wrote:
> 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).
> 
> 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.
>   - 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.
> 
> 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] https://reviews.llvm.org/D66195
> [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html
> [2] https://reviews.llvm.org/D74258
> [3] https://reviews.llvm.org/D74145



> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev


-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200211/005e3d7a/attachment.sig>


More information about the Openmp-dev mailing list