unable to make Chapel on SGI machine w/ Intel

[sdbachman]

I was unable to progress through the Quickstart on NCAR's computer cluster Cheyenne (https://arc.ucar.edu/knowledge_base/70549542). I had our Intel module loaded, and executing the make command returns the following error:

(base) bachman@cheyenne6:/glade/scratch/bachman/chapel> make Making the compiler... make[2]: Nothing to be done for 'llvm'. make[2]: Nothing to be done for 'jemalloc'. adt/ icpc -c -O3 -I. -I../include/linux64 -I../include -I../../build/compiler/linux64/intel/x86_64/hostmem-cstdlib/llvm-none/14/san-none -I../../runtime/include/encoding -I/glade/scratch/bachman/chapel/third-party/utf8-decoder -I../dyno/include -I/glade/scratch/bachman/chapel/third-party/llvm/install/support-only-linux64-x86_64/include -std=c++14 -fno-exceptions -fno-rtti -D_GNU_SOURCE -D_DEBUG -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Wno-comment -DNDEBUG -DCOMPILER_SUBDIR=adt -o ../../build/compiler/linux64/intel/x86_64/hostmem-cstdlib/llvm-none/14/san-none/adt/vec.o vec.cpp In file included from ../dyno/include/chpl/framework/UniqueString-detail.h(30), from ../dyno/include/chpl/framework/UniqueString.h(28), from ../dyno/include/chpl/framework/ID.h(23), from ../include/astlocs.h(27), from ../include/baseAST.h(40), from ../include/misc.h(27), from vec.cpp(53): ../dyno/include/chpl/framework/stringify-functions.h(194): error: namespace "std" has no member "index_sequence" std::index_sequence<I...>) { ^

In file included from ../dyno/include/chpl/framework/UniqueString-detail.h(30), from ../dyno/include/chpl/framework/UniqueString.h(28), from ../dyno/include/chpl/framework/ID.h(23), from ../include/astlocs.h(27), from ../include/baseAST.h(40), from ../include/misc.h(27), from vec.cpp(53): ../dyno/include/chpl/framework/stringify-functions.h(194): error: expected a ")" std::index_sequence<I...>) { ^

In file included from ../dyno/include/chpl/framework/UniqueString.h(30), from ../dyno/include/chpl/framework/ID.h(23), from ../include/astlocs.h(27), from ../include/baseAST.h(40), from ../include/misc.h(27), from vec.cpp(53): ../dyno/include/chpl/util/hash.h(86): error: namespace "std" has no member "index_sequence" inline size_t hash_tuple_impl(const TUP& tuple, std::index_sequence<I...>) { ^

In file included from ../dyno/include/chpl/framework/UniqueString.h(30), from ../dyno/include/chpl/framework/ID.h(23), from ../include/astlocs.h(27), from ../include/baseAST.h(40), from ../include/misc.h(27), from vec.cpp(53): ../dyno/include/chpl/util/hash.h(86): error: expected a ")" inline size_t hash_tuple_impl(const TUP& tuple, std::index_sequence<I...>) { ^

compilation aborted for vec.cpp (code 2) ../make/Makefile.compiler.foot:55: recipe for target '../../build/compiler/linux64/intel/x86_64/hostmem-cstdlib/llvm-none/14/san-none/adt/vec.o' failed make[3]: [../../build/compiler/linux64/intel/x86_64/hostmem-cstdlib/llvm-none/14/san-none/adt/vec.o] Error 2 make/Makefile.compiler.foot:29: recipe for target 'adt.makedir' failed make[2]: [adt.makedir] Error 2 Makefile:78: recipe for target 'compiler' failed make[1]: [compiler] Error 2 Makefile:59: recipe for target 'comprt' failed make: [comprt] Error 2

[bradcray]

My first reaction to this was surprise ("We test with intel nightly") but after a few moments, I realized that we may no longer test building the compiler with intel (?). Or, if we do, maybe we're just using a different/older version.

Interestingly, I believe that the way @sdbachman ran into this was by loading an intel-providing compiler module on his system, which set CC/CXX, which caused intel to be used for both HOST and TARGET compiler (as he had CHPL_LLVM=none due to quickstart settings and/or desire not to build a bundled LLVM). That feels like a pretty obvious pitfall for a user to step into if we don't test building the compiler with icpc and suggests maybe CC/CXX should not affect the CHPL_HOST_COMPILER choice?

Tagging @mppf to check my work here.

[mppf]

@bradcray - interestingly, with PrgEnv compilers, we made the opposite choice -- CC / CXX impacts only the host compiler (see also discussion in #18450). I suspect that there isn't really a way to succeed in all cases with the default behavior here.

Regarding the error, we have this:

icpc -c -O3 ... -std=c++14 error: namespace "std" has no member "index_sequence"

This probably means that @sdbachman does not have a working C++14 compiler. Note that some compilers use the system C++ standard library rather than always including their own. I think this is to help with compatibility with libraries compiled with the system C++ compiler. In particular, even if you are using a recent enough Intel compiler, if that is trying to use the system libstdc++, and the system libstdc++ is really old, then it won't have working C++14 support.

@sdbachman - were you able to work around the issue here by using a different compiler?