Bumping compiler version requirements

[atgeirr]

There has been some confusion and back-and-forth about compiler requirements and C++20 features we can use in code. See comments in #5070 and #5083 for example.

We already made the move to C++20 in #4997 on February 20. There was no negative feedback at that time, but plenty of positive feedback. The PR also stated that while gcc 12 would likely be sufficient initially, gcc 14 would be needed eventually. Following this, some refactoring to use std::ranges was also performed, and no problems were reported.

However std::format has caused concern for users of gcc 12, which does not support that. And using a new compiler is as far as I understand not simply a question of apt-get new compiler, but requires operating system upgrade for popular distros like Ubuntu (where our support is stated as the last two LTS versions, meaning 24.04 and 26.04 for our upcoming 2026.04 release) or debian (which we do not formally support, but in practice have done, especially as we use it for the Jenkins server).

It is understandable that one wants to postpone for as long as possible upgrading, which is disruptive to daily work. In the interest of minimizing disruption I suggest the following:

• We hold back on using C++20 features that are unsupported in gcc 12 (such as std::format) until after the upcoming release branches have been created. This should happen quite soon, although a timeline for the release has not been decided yet. After that point we do allow gcc 14 supported features in the main branches (but not in the release). That way the release may be compiled with gcc 12.
• The upcoming release will still NOT officially support Ubuntu 22.04, but bump as usual (outlined above).
• If we discover any clang-related issue we bring them up as needed, at this point I am not aware of any. And the problem caused by the tight coupling of distro and compiler version does not apply to clang users to the same extent, I believe.

[kjetilly]

And using a new compiler is as far as I understand not simply a question of apt-get new compiler, but requires operating system upgrade for popular distros like Ubuntu

At least on the supported Ubuntu 22.04, you can install gcc-14 by doing (I tested it now)

add-apt-repository ppa:ubuntu-toolchain-r/test
apt-get update
apt-get install -y gcc-14 g++-14 gfortran-14

ie, no OS upgrade needed. With that installed, you either specify -DCMAKE_{C,CXX,Fortran}_COMPILER to be /usr/bin/g{cc,++,fortran}-14} when you run cmake (or store it in a cache file, or export env vars, or..), or you run

update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-14 100
update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-14 100
update-alternatives --install /usr/bin/gfortran gfortran /usr/bin/gfortran-14 100

to make it the system defaults.

On Debian (Bookworm), you might get away with pulling some packages from Testing, you should also be able to compile it manually by doing something like (I tested it in a Dockerfile at it seems to compile just fine, the same approach can be done to install the compiler locally in a user HOME folder if one lacks admin rights) :

GCC_VERSION="${GCC_VERSION:-14.3.0}"
PREFIX="${PREFIX:-/opt/gcc-14}"

wget https://gcc.gnu.org/pub/gcc/releases/gcc-${GCC_VERSION}/gcc-${GCC_VERSION}.tar.xz
tar -xf gcc-${GCC_VERSION}.tar.xz

cd "gcc-${GCC_VERSION}"

# Download prerequisites
./contrib/download_prerequisites

# Create build dir (out-of-tree)
cd ..
mkdir -p build
cd build

# Configure
../gcc-${GCC_VERSION}/configure \
    --prefix="${PREFIX}" \
    --enable-languages=c,c++,fortran \
    --disable-multilib

make 
sudo make install-strip

and then again specifying /opt/gcc-14/bin/gcc etc to cmake.

On Debian, the following is a prerequisite for compiling gcc-14:

        build-essential \
        flex \
        bison \
        gawk \
        texinfo \
        wget \
        xz-utils \
        file \
        perl \
        python3 \
        ca-certificates

[alfbr]

This has bitten us too. I am very grateful that you are going the pragmatic route here, not breaking GCC 12. Generally speaking we need to be more conservative on changes to the build system than what has been practice the last couple of months. Having frequent build breakage is a significant cost. Of course everything is possible, and we are right now compiling against a manually compiled GCC stack as a stop gap solution. BTW, we are not able to do our work again today, build is still broken here.

[blattms]

I will write a more elaborate answer, later.

Generally, my opinion is that we should not close doors lightly that are hard to open again, if there is no good reason for it. We should check on what systems other than workstations OPM is used on, e.g. HPC systems. E.g. there is a two year old issue from someone that would have needed gcc-8 support at that time, see #3798.

[kjetilly]

I think if requirements to compilers are added, it is a good idea to have both feature checks and version checks in the CMake files. So concretely if one wanted to require std::format, one would get an error message from the cmake stage that gcc-12 was not supported. This will least remove needless debugging when you suddenly realize the code does not compile anymore.

And having strict version checks can also be a good idea, like how ResInsight requires GCC-13 or clang-19 . This will help people so that they don't have to search aimlessly for bumping up GCC versions as the Issue Markus linked to.

For the feature check of std::format, one could have added:

check_cxx_source_compiles("
#include <format>
#include <string>

int main() {
    std::string s = std::format(\"Hello {}\", 42);
    return 0;
}
" HAS_STD_FORMAT)

if(NOT HAS_STD_FORMAT)
   message(FATAL_ERROR
    "std::format is required.\n"
    "GCC >= 14 recommended."
)
endif()

which would have give the cmake error message:

std::format required.
GCC>=14 recommended.