C++14/C++17 in LAMMPS

[rbberger]

Summary

It's been 4 years since issue #1659 (2019), where we kept track of the C++11 transition for LAMMPS, and 3 years (2020) since C++11 was allowed in LAMMPS core.

In a similar way, this issue now documents the current state of common compilers among popular Linux distributions.
By now, moving to C++14 is a trivial change, since most compilers at least default to C++14, if not already C++17.

The only exception is the default RHEL7 compiler, which barely supports C+11. I personally don't consider this a blocker, given that most HPC centers, even if they still use RHEL7-based systems, will provide newer GCC compilers.

As a side note, GCC versions prior to v9.x should not be used for C++17 due to various quirks and bugs.

Currently, C++17 is currently only required by KOKKOS 4.

Proposal to assess impact

// for C++14
#ifndef LAMMPS_CXX14
#if __cplusplus <= 201402L
  #error LAMMPS is planning to transition to C++14. Do disable this error please use a C++14-compliant compiler or define LAMMPS_CXX14 in your makefile
#endif
#endif

// alternative for C++17
#ifndef LAMMPS_CXX17
#if __cplusplus <= 201703L
  #error LAMMPS is planning to transition to C++17. Do disable this error please use a C++17-compliant compiler or define LAMMPS_CXX17 in your makefile
#endif
#endif

Target Platforms

OS	g++ Version	g++ default	clang++ Version	clang++ default
Ubuntu 18.04 LTS	7.4.0	C++14	6.0.0	C++14
Ubuntu 20.04 LTS (EOS 04/2023)	9.4.0	C++14	10.0.0	C++14
Ubuntu 22.04 LTS (EOS 04/2027)	11.3.0	C++17	14.0.0	C++14
Ubuntu 23.04	12.2.0	C++17	15.0.7	C++14
RHEL7 (EOL July 2024)	4.8.5	C++98 (up to C++11 with -std=c++11)	3.4.2	C++98 (up to C++11 with -std=c++11)
RHEL 8	8.5.0	C++14	15.0.7	C++14
RHEL 9	11.3.1	C++17	15.0.7	C++14
Fedora 37 (EOL 12/15/2023)	12.2.0	C++14	15.0.7	C++14
Fedora 38	13.0.1	C++17	16.0.5	C++17
OpenSuse Leap 15	7.3.9	C++14	15.0.7	C++14
OpenSuse Tumbleweed	13.1.1	C++17	16.0.6	C++17

Testing default C++ compiler standard

g++ -dM -E -x c++  /dev/null | grep -F __cplusplus

References:

• https://en.cppreference.com/w/cpp/compiler_support

[akohlmey]

Unlike with C++11 there is currently little external pressure from contributors to use a more recent C++ standard.

Internally, there is currently only Kokkos requiring a post-C++11 standard.

The latest Googletest release (1.13) requires C++14, but we don't use any of its features, so we can stick with version 1.12 for now. It also would not be a problem to raise the C++ standard only for testing, since this is not considered a core functionality of LAMMPS from the user perspective (very few users enable and use testing).

libfmt is "self-adapting" for C++11 to C++20. The latest development version still is compatible with C++11 without loss of functionality.

If we bring this to a LAMMPS developer discussion, there should be a list of benefits, i.e. new features or corrections in C++14 (or C++17?) that would have a positive impact on LAMMPS or could remove workarounds and/or inefficient or complex code. I would thus want to wait before adding the pre-processor check until a consensus about if and when to make a change is found.