Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation with GCC 8.2.0 fails #3798

Open
samfux84 opened this issue Nov 29, 2023 · 10 comments
Open

Compilation with GCC 8.2.0 fails #3798

samfux84 opened this issue Nov 29, 2023 · 10 comments

Comments

@samfux84
Copy link

samfux84 commented Nov 29, 2023

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
Copy link
Member

bska commented Nov 29, 2023

  • 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
Copy link
Member

blattms commented Nov 29, 2023

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
Copy link
Member

blattms commented Nov 29, 2023

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

@bska
Copy link
Member

bska commented Nov 29, 2023

with the following changes:

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

@samfux84
Copy link
Author

@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
Copy link
Member

bska commented Nov 30, 2023

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
Copy link
Author

samfux84 commented Nov 30, 2023

@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
Copy link
Member

blattms commented Feb 20, 2024

Have you been able to somehow resolve this?

@samfux84
Copy link
Author

No, I have not been able to resolve the issue

@blattms
Copy link
Member

blattms commented Feb 22, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants