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

[Jonas Hahnfeld via Openmp-dev]

Am Samstag, den 08.02.2020, 12:44 -0600 schrieb Johannes Doerfert:
> 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 don't see the merit and remain skeptical. From the post cited above,
which features would you want to use in the OpenMP runtimes?

> 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.

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.

>   - 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.

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

> 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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200210/a86da92d/attachment.sig>