[Openmp-dev] [RFC] Requiring C++14 for the OpenMP subproject
Jonas Hahnfeld via Openmp-dev
openmp-dev at lists.llvm.org
Mon Feb 10 13:06:47 PST 2020
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>
More information about the Openmp-dev
mailing list