OPM/opm-common

Compilation with GCC 8.2.0 fails

Opened this issue · 10 comments

samfux84 commented

Hi,

I am trying to build OPM-common (2023.10) on our HPC cluster. I use the following dependencies (all built from source code):

  • GCC 8.2.0
  • Dune 2.9.0
  • OpenMPI 4.1.4
  • Zoltan 3.901
  • OpenBLAS 0.3.15
  • Python 3.10.4
  • Suite-Sparse 5.10.1
  • BOOST 1.74.0
  • CMake 3.25.0

I follow the installation instructions and created the build directory, was running ccmake .. to change some variables (to disable the addition of -march=native, as we have different node types in the cluster). Then I was running make -j 8 to build the software in parallel. At 40% the compilation failed with the following error:

[ 40%] Building CXX object CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DFMT_HEADER_ONLY -DHAVE_CONFIG_H=1 -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/cjson -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build/include -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final -isystem /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/fmtlib/include -isystem /cluster/apps/gcc-8.2.0/boost-1.74.0-bwdibdtazuvem2m7bwkiifvh7b3xvd5y/include -pipe -Wall -Wextra -Wshadow -fopenmp -pthread -O3 -DNDEBUG -ftree-vectorize -march=core-avx2 -mavx2 -UNDEBUG -fPIC -fopenmp -std=c++17 -MD -MT MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o -MF  MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o.d -o CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o -c /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/Network/Node.cpp
In file included from /cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/memory:80,
                 from /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp:22:
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/bits/unique_ptr.h: In instantiation of ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = Opm::SegmentMatcher::Impl]’:
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/bits/unique_ptr.h:274:17:   required from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = Opm::SegmentMatcher::Impl; _Dp = std::default_delete<Opm::SegmentMatcher::Impl>]’
/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/opm/input/eclipse/Schedule/MSW/SegmentMatcher.hpp:351:34:   required from here
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/bits/unique_ptr.h:79:16: error: invalid application of ‘sizeof’ to incomplete type ‘Opm::SegmentMatcher::Impl’
  static_assert(sizeof(_Tp)>0,
                ^~~~~~~~~~~

I started searching the internet for this error message and found:

https://stackoverflow.com/questions/20934195/invalid-application-of-sizeof-to-incomplete-type-created-classes

which seems to discuss a similar error. Is this a known problem? And do you have any idea on how to resolve this error?

Any help is appreciated.

Best regards

Sam

bska commented
  • GCC 8.2.0

Do you have a way of testing GCC 9.x or later? This may be a compiler error or missing feature in GCC 8.x and/or a problem in the libstdc++ standard library implementation. The diagnostic message means that the compiler is unable to specialise std::default_delete<> for the incomplete type SegmentMatcher::Impl. The typical reason for this, in the context of the "pointer to implementation" idiom, is that there is no definition for the type's destructor in place. When using "pointer to implementation" we cannot rely on the compiler-generated destructor, exactly because the type of the implementation class is incomplete.

If you don't have an easy way of testing GCC 9.x, I'd like to run a little experiment if you wouldn't mind. Can you create the following three files (k.hpp, k.cpp, and main.cpp) and run following command on your mom node, please?

g++ -std=c++17 -Wall -Wextra -pedantic -o t main.cpp k.cpp && ./t

If all goes well the command should print

hello, pImpl

to the shell. If not, do you get anything else if you replace = default; with {} in k.cpp?

k.hpp

#include <memory>
#include <string>

class K
{
public:
    K();
    ~K();
    std::string str() const;
private:
    class Impl;
    std::unique_ptr<Impl> pImpl_;
};

k.cpp

#include "k.hpp"

class K::Impl
{
public:
    std::string str() const { return "pImpl"; }
};

K::K() : pImpl_ { std::make_unique<Impl>() } {}
K::~K() = default;
std::string K::str() const { return this->pImpl_->str(); }

main.cpp

#include "k.hpp"
#include <iostream>

int main()
{
    K k{};
    std::cout << "hello, " << k.str() << '\n';
}
blattms commented

That example compiles with g++-8 (g++-8 -std=c++17 -c k.cpp -o k.o; g++-8 -std=c++17 -o main main.cpp k.o) with
the following changes:

diff --git a/k.hpp b/k.hpp
index 396e94a..7c3a416 100644
--- a/k.hpp
+++ b/k.hpp
@@ -1,4 +1,5 @@
 #include <string>
+#include <memory>
 
 class K
 {
blattms commented

Well, at least with g++-8.3.0-6 on Debian, which might have additional patches applied.

bska commented

with the following changes:

Hm, weird. Did you have to #include <memory> twice? The original k.hpp did include that header...

samfux84 commented

@bska Thank you for the fast and helpful reply and for providing the code example. Next to GCC 8.2.0, I can also use GCC 9.3.0 or 11.4.0 (for those I just need to build a few missing dependencies like zoltan, but this should not take a lot of time). The example seems to build fine with all 3 compilers:

GCC 8.2.0:

[sfux@eu-login-12 opm]$ module load gcc/8.2.0

The following have been reloaded with a version change:
  1) gcc/4.8.5 => gcc/8.2.0

[sfux@eu-login-12 opm]$ g++ -std=c++17 -Wall -Wextra -pedantic -o t main.cpp k.cpp && ./t
hello, pImpl
[sfux@eu-login-12 opm]$

GCC 9.3.0:

[sfux@eu-login-12 opm]$ module load gcc/9.3.0

The following have been reloaded with a version change:
  1) gcc/4.8.5 => gcc/9.3.0

[sfux@eu-login-12 opm]$ g++ -std=c++17 -Wall -Wextra -pedantic -o t main.cpp k.cpp && ./t
hello, pImpl
[sfux@eu-login-12 opm]$

GCC 11.4.0:

[sfux@eu-login-12 opm]$ module load gcc/11.4.0

The following have been reloaded with a version change:
  1) gcc/4.8.5 => gcc/11.4.0

[sfux@eu-login-12 opm]$ g++ -std=c++17 -Wall -Wextra -pedantic -o t main.cpp k.cpp && ./t
hello, pImpl
[sfux@eu-login-12 opm]$

What also confuses me a bit is, that when the compilation fails and I rerun the command that failed:

/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DFMT_HEADER_ONLY -DHAVE_CONFIG_H=1 -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/cjson -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build/include -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final -isystem /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/fmtlib/include -isystem /cluster/apps/gcc-8.2.0/boost-1.74.0-bwdibdtazuvem2m7bwkiifvh7b3xvd5y/include -pipe -Wall -Wextra -Wshadow -fopenmp -pthread -O3 -DNDEBUG -ftree-vectorize -march=core-avx2 -mavx2 -UNDEBUG -fPIC -fopenmp -std=c++17 -MD -MT MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o -MF MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o.d -o CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o -c /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/Network/Node.cpp

then this particular file Node.cpp compiles without error. Could the issue be related to CMake?

Best regards

Sam

bska commented

What also confuses me a bit is, that when the compilation fails and I rerun the command that failed:

/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/bin/g++ \
   -DBOOST_ALL_NO_LIB \
   -DBOOST_SYSTEM_DYN_LINK \
   -DFMT_HEADER_ONLY \
   -DHAVE_CONFIG_H=1 \
   -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build \
   -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/cjson \
   -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/build/include \
   -I/scratch/tmp.37674213.sfux/opm-common-release-2023.10-final \
   -isystem \
   /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/external/fmtlib/include \
   -isystem \
   /cluster/apps/gcc-8.2.0/boost-1.74.0-bwdibdtazuvem2m7bwkiifvh7b3xvd5y/include \
   -pipe \
   -Wall \
   -Wextra \
   -Wshadow \
   -fopenmp \
   -pthread \
   -O3 \
   -DNDEBUG \
   -ftree-vectorize \
   -march=core-avx2 \
   -mavx2 \
   -UNDEBUG \
   -fPIC \
   -fopenmp \
   -std=c++17 \
   -MD \
   -MT MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o \
   -MF MakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o.d \
   -o CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/Network/Node.cpp.o \
   -c /scratch/tmp.37674213.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/Network/Node.cpp

then this particular file Node.cpp compiles without error.

Right. To be honest, I think Node.cpp is innocent here. That file does not invoke the SegmentMatcher. I assume you ran your build in parallel, i.e., make -j N or similar (e.g., cmake --build . --target all --parallel N). In that case, it is likely that building Node.cpp just happened to coincide in time with another compiler instance detecting a problem in a different file–probably src/opm/input/eclipse/Schedule/MSW/SegmentMatcher.cpp. If you did run a build in parallel, I think we'll get a clearer diagnostic message if you "just" run one compilation at a time, e.g.,

cmake --build . -target all --parallel 1

from the top-level build directory. This will definitely take longer and it's not something we do regularly, but when debugging build problems it's often a good thing to try first.

I'd very much like to know what diagnostics you get from GCC 8.2 in this instance.

samfux84 commented

@bska Thank you for your reply.

I tried running the command that you provided for serial compilation. Now the compilation fails at 50%

[ 50%] Building CXX object CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp.o
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DFMT_HEADER_ONLY -DHAVE_CONFIG_H=1 -I/scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/build -I/scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/external/cjson -I/scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/build/include -I/scratch/tmp.38104216.sfux/opm-common-release-2023.10-final -isystem /scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/external/fmtlib/include -isystem /cluster/apps/gcc-8.2.0/boost-1.74.0-bwdibdtazuvem2m7bwkiifvh7b3xvd5y/include -isystem /scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/python/pybind11/include -isystem /cluster/apps/nss/gcc-8.2.0/python/3.10.4/x86_64/include/python3.10 -pipe -Wall -Wextra -Wshadow -fopenmp -pthread -O3 -DNDEBUG -ftree-vectorize -march=core-avx2 -mavx2 -UNDEBUG -fPIC -fopenmp -std=c++17 -MD -MT CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp.o -MF CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp.o.d -o CMakeFiles/opmcommon.dir/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp.o -c /scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp
In file included from /cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/memory:80,
                 from /scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/src/opm/input/eclipse/Schedule/KeywordHandlers.cpp:22:
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/bits/unique_ptr.h: In instantiation of ‘void std::default_delete<_Tp>::operator()(_Tp*) const [with _Tp = Opm::SegmentMatcher::Impl]’:
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/bits/unique_ptr.h:274:17:   required from ‘std::unique_ptr<_Tp, _Dp>::~unique_ptr() [with _Tp = Opm::SegmentMatcher::Impl; _Dp = std::default_delete<Opm::SegmentMatcher::Impl>]’
/scratch/tmp.38104216.sfux/opm-common-release-2023.10-final/opm/input/eclipse/Schedule/MSW/SegmentMatcher.hpp:351:34:   required from here
/cluster/spack/apps/linux-centos7-x86_64/gcc-4.8.5/gcc-8.2.0-6xqov2fhvbmehix42slain67vprec3fs/include/c++/8.2.0/bits/unique_ptr.h:79:16: error: invalid application of ‘sizeof’ to incomplete type ‘Opm::SegmentMatcher::Impl’
  static_assert(sizeof(_Tp)>0,
                ^~~~~~~~~~~

Please find in the attachment the complete build logs (testmake.log).

Thank you for helping me with this issue.
testmake.log

blattms commented

Have you been able to somehow resolve this?

samfux84 commented

No, I have not been able to resolve the issue

blattms commented

Mmh. But you seem to have other compilers available. Do you need to to stick to 8.* because of other dependencies?