[Openmp-commits] [PATCH] D149726: [OpenMP] Use CMAKE_CXX_STANDARD for setting the C++ version

Thu May 11 18:23:34 PDT 2023

MaskRay accepted this revision.
MaskRay added a comment.

In D149726#4315555 <https://reviews.llvm.org/D149726#4315555>, @tianshilei1992 wrote:

> `libomp` is widely used and it only uses a small set of C++ features. Due to some historical issue that `libomptarget` and `libomp` are in the same `openmp` directory but their developments are quite diverged. I can see requiring C++17 for `libomp` will definitely break a lot user's build. That will need to be further discussed in our weekly multi-company meeting. The patch mentioned in the description didn't consider the special situation we have for `libomp`. If necessary, we might revert it in the future.

I don't understand this statement that requiring C++17 for `libomp` will definitely break a lot of users builds.
Isn't that libomp is mostly built in C++17 modes, except in the `OPENMP_STANDALONE_BUILD` mode on some Windows configurations due to unrecognized `-std=c++17`?

The `-std=c++17` occurrences in existing openmp/ files well suggest that requiring C++17 is intended (af28b27d31a5c13c31769c8551ffdcdc469fd5f4 <https://reviews.llvm.org/rGaf28b27d31a5c13c31769c8551ffdcdc469fd5f4> (2022-08)).

Please be more specific what other configurations you'd like to support. If you want more builds supported I'd like to see a proposal for OpenMP like https://discourse.llvm.org/t/rfc-stand-alone-build-support/61291 (RFC: Stand-alone build support).
Having no build bot for the configuration you care about and making a statement "it will break a lot of users builds" just creates a "haunted graveyard" <https://www.usenix.org/sites/default/files/conference/protected-files/srecon17americas_slides_reese.pdf> situation.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149726/new/

https://reviews.llvm.org/D149726