Build failure for Intel C++ with -std=c++17 and libstdc++ from GCC 9.2

[Paul Hargrove]

As shown below, icpc is producing errors very similar to PGI's in issue #290, when passed -std=c++17 (or `-std=c++2a, fwiw). Just as in that issue, I am uncertain if g++'s headers are the true problem.

Using nobs run test/hello_upcxx.cpp reproduces the same errors as in issue #290.
So the build infrastructure change is not related.

/usr/local/pkg/intel/2020/compilers_and_libraries_2020.0.166/linux/bin/intel64/icpc -std=c++17   -D_GNU_SOURCE=1 -D
GASNET_SEQ     -I/home/pcp1/phargrov/upcxx/ICPC-2a/bld/GASNet-stable -I/home/pcp1/phargrov/upcxx/ICPC-2a/bld/GASNet
-stable/smp-conduit -I/home/pcp1/phargrov/upcxx/ICPC-2a/bld/GASNet-stable/other   -I/home/pcp1/phargrov/upcxx/ICPC-
2a/bld/GASNet-stable/extended-ref/vis -I/home/pcp1/phargrov/upcxx/ICPC-2a/bld/GASNet-stable/extended-ref/coll -I/ho
me/pcp1/phargrov/upcxx/ICPC-2a/bld/GASNet-stable/extended-ref/ratomic -I/home/pcp1/phargrov/upcxx/ICPC-2a/bld/GASNe
t-stable/extended-ref -I/home/pcp1/phargrov/upcxx/ICPC-2a/bld/gasnet.debug   -g   -wd654 -wd1125 -wd279 -wd1572
  -DUPCXX_ASSERT_ENABLED=1 -DUPCXX_BACKEND=1 -DUPCXX_MPSC_QUEUE_ATOMIC=1 -DUPCXX_BACKEND_GASNET_SEQ=1 -I/home/pcp1/
phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include  -c /home/pcp1/phargrov/upcxx/src/b
ackend/gasnet/noise_log.cpp -o noise_log.o
In file included from /home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/up
cxx/team.hpp(4),
                 from /home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/up
cxx/backend.hpp(7),
                 from /home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/upcxx/backend/gasnet/runtime_internal.hpp(12),
                 from /home/pcp1/phargrov/upcxx/src/backend/gasnet/noise_log.cpp(2):
/usr/local/pkg/gcc/9.2.0/include/c++/9.2.0/tuple(553): error: pack "_UElements" does not have the same number of elements as "_Elements"
            __and_<is_nothrow_assignable<_Elements&, _UElements>...>::value;
                                                     ^
          detected during:
            instantiation of "bool std::tuple<_Elements...>::__nothrow_assignable<_UElements...>() [with _Elements=<upcxx::team &>, _UElements=<>]" at line 49 of "/home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/upcxx/future/impl_result.hpp"
            instantiation of class "upcxx::detail::future_impl_result<T...> [with T=<upcxx::team &>]" at line 80 of "/home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/upcxx/future/future1.hpp"
            instantiation of class "upcxx::future1<Kind, T...> [with Kind=upcxx::detail::future_kind_result, T=<upcxx::team &>]" at line 75 of "/home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/upcxx/future/make_future.hpp"
            instantiation of "auto upcxx::make_future(T...) [with T=<upcxx::team &>]" at line 46 of "/home/pcp1/phargrov/upcxx/ICPC-2a/bld/upcxx.assert1.optlvl0.dbgsym1.gasnet_seq.smp/include/upcxx/team_fwd.hpp"

compilation aborted for /home/pcp1/phargrov/upcxx/src/backend/gasnet/noise_log.cpp (code 2)

[Paul Hargrove]

My testing using --with-gxx='icpc -std=c++17 -gxx-name=/usr/local/pkg/gcc/8.3.0/bin/g++' appears to work. The use of -gxx-name=... changes the libstdc++ being used, and also works at -std=c++2a.

So, I think this is (as was speculated in similar issue #290) an incompatibility between Intel's compiler and the GNU libstdc++ headers from GCC-9.2.0.

I have changed our Intel compiler installs to default to -gxx-name=/usr/local/pkg/gcc/8.3.0/bin/g++ rather than GCC 9.2.0.

I believe this problem is more likely an "external" issue than our own.
Specifically, I believe my installation of the Intel compilers against GCC-9.2 was erroneous.
So I am changing the issue metadata accordingly.

[Paul Hargrove]

Anyone wanting to reproduce on Dirac (now that I've changed the installs default) can do so by configuring UPC++ using --with-cxx='icpc -gxx-name=/usr/local/pkg/gcc/9.2.0/bin/g++'

[Andrew McArdle]

I am trying to compile metahipmer on our HPC. I managed to compile latest UPC++ without apparent issue, having loaded intel-suite/2020.2 and gcc/10.2.0. When I tried to compile metahipmer (after loading cmake/3.18.2), I received pages of errors like those above, e.g.:

‌

/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/tuple(566): error: pack "_UElements" does not have the same number of elements as "_Elements"
            __and_<is_nothrow_constructible<_Elements, _UElements>...>::value;
                                                       ^
          detected during:
            instantiation of "bool std::tuple<_Elements...>::__nothrow_constructible<_UElements...>() [with _Elements=<upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>> &>, _UElements=<>]" at line 122 of "/rds/general/user/ajm3018/home/upcxx-2021.3.0/upc/upcxx.opt.gasnet_seq.smp/include/upcxx/dist_object.hpp"
            instantiation of "upcxx::dist_object<T>::dist_object(T, const upcxx::team &) [with T=std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>]" at line 150 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/ext/new_allocator.h"
            instantiation of "void __gnu_cxx::new_allocator<_Tp>::construct(_Up *, _Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Up=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>,
                      upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 512 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/alloc_traits.h"
            instantiation of "void std::allocator_traits<std::allocator<_Tp>>::construct(std::allocator_traits<std::allocator<_Tp>>::allocator_type &, _Up *, _Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Up=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>,
                      _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 552 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/shared_ptr_base.h"
            instantiation of "std::_Sp_counted_ptr_inplace<_Tp, _Alloc, _Lp>::_Sp_counted_ptr_inplace(_Alloc, _Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Alloc=std::allocator<upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>>, _Lp=__gnu_cxx::_S_atomic,
                      _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 683 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/shared_ptr_base.h"
            instantiation of "std::__shared_count<_Lp>::__shared_count(_Tp *&, std::_Sp_alloc_shared_tag<_Alloc>, _Args &&...) [with _Lp=__gnu_cxx::_S_atomic, _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Alloc=std::allocator<upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>>,
                      _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 1372 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/shared_ptr_base.h"
            instantiation of "std::__shared_ptr<_Tp, _Lp>::__shared_ptr(std::_Sp_alloc_shared_tag<_Alloc>, _Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Lp=__gnu_cxx::_S_atomic, _Alloc=std::allocator<upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>>,
                      _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 409 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/shared_ptr.h"
            instantiation of "std::shared_ptr<_Tp>::shared_ptr(std::_Sp_alloc_shared_tag<_Alloc>, _Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Alloc=std::allocator<upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>>, _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int},
                      std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 860 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/shared_ptr.h"
            instantiation of "std::shared_ptr<_Tp> std::allocate_shared<_Tp,_Alloc,_Args...>(const _Alloc &, _Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Alloc=std::allocator<upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>>,
                      _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 876 of "/rds/general/applications/gcc/10.2.0/bin/../include/c++/10.2.0/bits/shared_ptr.h"
            instantiation of "std::shared_ptr<_Tp> std::make_shared<_Tp,_Args...>(_Args &&...) [with _Tp=upcxx::dist_object<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>>, _Args=<std::tuple<std::shared_ptr<std::vector<upcxx::intrank_t={int}, std::allocator<int>>>, upcxx::promise<>, upcxx::promise<>>, const upcxx::team &>]" at line 757 of
                      "/rds/general/user/ajm3018/home/mhm2-2.0.1/upcxx-utils/include/upcxx_utils/reduce_prefix.hpp"
            instantiation of "upcxx::future<> upcxx_utils::reduce_prefix_auto_choice_local(const T *, T *, size_t={unsigned long}, const BinaryOp &, const upcxx::team &, bool, const upcxx::team &) [with T=int, BinaryOp=upcxx::detail::op_wrap<upcxx::detail::opfn_min_not_max<true>, true>]" at line 5 of "/rds/general/user/ajm3018/home/mhm2-2.0.1/.build/upcxx-utils/src/reduce_prefix-extern-template-int-min_not_max-true.cpp"

Is my error likely related to the same issue, and do you have any ideas how I might bypass it?

Thanks,

Andrew

[Dan Bonachea]

Hi @Andrew McArdle - This looks like a known incompatibility between the Intel compiler and the (much newer) stdc++ headers provided by gcc/10.2.0.

The most likely workaround is to either install a newer Intel compiler, or point your existing Intel compiler at an older gcc install for the libraries.

For details on how to do this, see https://bitbucket.org/berkeleylab/upcxx/wiki/docs/alt-compilers#markdown-header-intel

[Andrew McArdle]

Thanks very much for the advice. Older gcc is the easiest - pre 9.2 I suspect from above. Because I am very much inexpert on C and compilers, can I check whether we are talking about doing this and recompiling upcxx itself (which did not fail), or simply using the older gcc to compile metahipmer while still using the existing compiled upcxx? Thanks!

[Dan Bonachea]

are talking about doing this and recompiling upcxx itself (which did not fail), or simply using the older gcc to compile metahipmer while still using the existing compiled upcxx?

@Andrew McArdle: I highly recommend using the same compiler and stdc++ headers for both upcxx build/install and application build. This is nothing specific to UPC++, it's just a general rule for using C++ safely that all objects should use the same compiler and stdc++ headers. The upcxx installation process doesn't link anything, but libupcxx will have link dependencies based on the stdc++ headers used - so you are likely to get link errors or other problems if you swap in a different libstdc++ without rebuilding upcxx.

[Andrew McArdle]

That’s very helpful @Dan Bonachea . Makes sense, and means I don’t get to be lazy!

[Andrew McArdle]

So I’ve now got upcxx compiled with GCC 8.2.0. However, metahipmer requires cmake >= 3.10. The nearest we have is 3.14.0. However, when I try to compile I get a cmake error which I think indicates the two versions are incompatible:

CMake Error in /home/mhm2-2.0.1/.build/CMakeFiles/CMakeTmp/CMakeLists.txt:
  Target "cmTC_26cdf" requires the language dialect "CXX17" , but CMake does
  not know the compile flags to use to enable it.


CMake Error at /rds/general/applications/cmake/3.14.0/share/cmake-3.14/Modules/CheckCXXSourceCompiles.cmake:110 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  /rds/general/applications/cmake/3.14.0/share/cmake-3.14/Modules/CheckCXXCompilerFlag.cmake:50 (CHECK_CXX_SOURCE_COMPILES)
  CMakeLists.txt:122 (check_cxx_compiler_flag)

I can’t work out how to determine which versions will satisfy both requirements, but post this in case you know an obvious solution!

Thanks, Andrew

[Dan Bonachea]

@Andrew McArdle : This CMake error no longer seems relevant to this original issue that you appended to. Can you please open a new issue?

Additionally, the new symptom seems more likely to be a MHM2 issue than a UPC++ one, so I suggest you use the MHM2 issue tracker.

[Andrew McArdle]

I’ll do that. Sorry for misposting here. Thanks for your help