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.
Strongly in favour of the OpenMP subproject using exactly the same compilation requirements as the LLVM project. C++ version, compiler versions and so forth.
I thought this was so obviously correct that we could patch the cmake and move on, but here we are. Thank you for writing the RFC.
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?
> 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?
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.
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.
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?
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.
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.
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).
