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

[Hal Finkel via Openmp-dev]

On 2/10/20 4:28 PM, Johannes Doerfert via Openmp-dev wrote:
> 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.


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.

  -Hal


>
> 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
>>>
>>>
>
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200210/af77cadf/attachment.html>