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

[Johannes Doerfert via Openmp-dev]

On 02/10, Jonas Hahnfeld wrote:
> 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?

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.

Cheers,
  Johannes

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



-- 

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/20200210/ac0e82dd/attachment.sig>