Project

General

Profile

Bug #1560

icc build fails on NASA Pleiades

Added by Thomas Quinn about 2 years ago. Updated over 1 year ago.

Status:
Merged
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
05/14/2017
Due date:
% Done:

0%


Description

Building with
./build ChaNGa verbs-linux-x86_64 cuda smp icc -j8 --with-production
gives errors like:
../bin/charmc -optimize -production -I. -c -o DummyLB.o DummyLB.C
In file included from sdag.h(28),
from CkMarshall.decl.h(6),
from charm++.h(134),
from LBDatabase.decl.h(3),
from LBDatabase.h(100),
from BaseLB.h(9),
from CentralLB.h(9),
from DummyLB.h(9),
from DummyLB.C(6):
../bin/../include/pup_stl.h(51): error: namespace "std" has no member "unique_pt
r"
inline void operator|(er &p, std::unique_ptr<T, std::default_delete<T>> &ptr
);
^
Here is the icc version: icc -v
icc version 16.0.2 (gcc version 4.3.0 compatibility)


Related issues

Related to Charm++ - Bug #1372: Using GCC-6 in support of Intel icc/icpc on Edison fails with no member "iterator_category" Closed 01/20/2017
Related to Charm++ - Bug #1377: linking megatest on Eos fails with undefined references to ceil and floor from hashtable_c++0x.cc Closed 01/22/2017
Related to Charm++ - Bug #740: charmrun.C compile fails on PSC Blacklight with icc 15.0.1 and gcc/g++ = 4.3.x Merged 05/15/2015

History

#1 Updated by Thomas Quinn about 2 years ago

That last line was a clue: it looks like the intel compiler depends on the g++ libraries, so a modern gcc has to be loaded as well as the intel compiler. On pleiades:
module load gcc
module load comp-intel
is needed.

#2 Updated by Sam White about 2 years ago

Yes, that is true on a few other systems too. AFAIK we decided to require at least gcc v4.4 headers for 6.8.0, and we are planning for future releases after 6.8 to require full C++11 support. Phil knows more about the specifics here.

#3 Updated by Phil Miller about 2 years ago

  • Subject changed from icc build fails on NAS Pleiades to icc build fails on NASA Pleiades
  • Target version set to 6.8.0

We ran into the exact same issue on some of the NERSC Cray systems.

We could maybe push a test that would trigger this failure into the configure process, and give a more explicit error explaining what went wrong and how to fix it. In the meanwhile, it should probably get at least a release notes entry.

#4 Updated by Phil Miller about 2 years ago

  • Assignee set to Phil Miller

#5 Updated by Sam White about 2 years ago

If we don't catch this during configure and abort with a message explaining why it failed, I think we're basically asking for future emails to the charm mailing list about it.

#6 Updated by Phil Miller about 2 years ago

Notes on the errors encountered with different icc/gcc version matchups:

gcc \ Intel 12 13 14 15 16 17
4.3 (Edison default) unique_ptr not defined in std unique_ptr not defined in std
4.4 module won't load - conflict module won't load - conflict module won't load - conflict module won't load - conflict module won't load - conflict with intel module module won't load - conflict with intel module
4.5 (edison n/a) - - - - - -
4.6 (edison n/a) - - - - - -
4.7 icpc: internal error: Assertion failed (shared/driver/drvutils.c, line 670) icpc: internal error: Assertion failed (shared/driver/drvutils.c, line 670)
4.8 good good
4.9 good
5.3 good with older PrgEnv-intel/5.1.29 good good good
6.1 see #1372 Error #3802: Version 16.0 Update 2 is incompatible with GNU versions greater than or equal to 6.0, due to an incomplete implementation of SFINAE which is used extensively in gcc6 headers. If you wish to proceed, use option -wd3802 good
6.2 Error #3802: Version 16.0 Update 2 is incompatible with GNU versions greater than or equal to 6.0, due to an incomplete implementation of SFINAE which is used extensively in gcc6 headers. If you wish to proceed, use option -wd3802 good

#7 Updated by Phil Miller about 2 years ago

  • Related to Bug #1372: Using GCC-6 in support of Intel icc/icpc on Edison fails with no member "iterator_category" added

#8 Updated by Phil Miller about 2 years ago

  • Related to Bug #1377: linking megatest on Eos fails with undefined references to ceil and floor from hashtable_c++0x.cc added

#9 Updated by Phil Miller about 2 years ago

  • Related to Bug #740: charmrun.C compile fails on PSC Blacklight with icc 15.0.1 and gcc/g++ = 4.3.x added

#10 Updated by Phil Miller about 2 years ago

The Intel 16 / GCC 6 combination errors at compile time. The configure output also shows error messages, but somehow doesn't detect those as failure, so it continues.

#11 Updated by Phil Miller about 2 years ago

  • Status changed from New to Implemented

#12 Updated by Phil Miller about 2 years ago

  • Status changed from Implemented to Merged

#13 Updated by Sam White about 2 years ago

  • Status changed from Merged to In Progress

This seems to have broken the Edison autobuild targets.

#14 Updated by Phil Miller about 2 years ago

  • Status changed from In Progress to Merged

Was working as intended. I had screwed up the login script configuration for the account used by autobuild, to say module load gcc/6.3.0 when the latest available was gcc/6.2.0. I switched it over to gcc/5.3.0 and confirmed that it now passes configure.

#15 Updated by Jim Phillips about 2 years ago

This test is now failing on my build box because it doesn't pass through the "-gcc-name=gcc44 -gxx-name=g++44" options included on the build command line to icpc, and just runs "icpc -I../include -I. -c test.cpp -o test.o -h std=c++11" instead.

#16 Updated by Phil Miller about 2 years ago

  • Status changed from Merged to In Progress

#17 Updated by Phil Miller about 2 years ago

Jim:
I think the definitive resolution of the exact issue you're now seeing would be to pass $OPTS to the various compilers as we test them in configure. That would be a fairly high-risk change, and I feel like we've tried that at some point in the past, and encountered a lot of trouble.

Here's my suggestion for what I think should be a fairly solid workaround - apply the following patch, and change your build line to something like the following:

OPTS_CC="-gcc-name=gcc44" OPTS_CXX="-gxx-name=g++44" ./build charm++ netlrts-linux-x86_64 --with-config-options -build-options etc

https://charm.cs.illinois.edu/gerrit/2564

I've tried this on my mac as follows:

OPTS_CXX=-std=c++1y ./build charm++ netlrts-darwin-x86_64
[...]
checking "C++ compiler as"... "clang++ -m64 -fPIC -dynamic -fno-common -mmacosx-version-min=10.7 -stdlib=libc++ -Wno-deprecated-declarations    -std=c++1y " 
checking "whether C++ compiler works"... "ok" 
checking "C++ linker as"... "clang++ -multiply_defined suppress -mmacosx-version-min=10.7 -Wl,-no_pie -stdlib=libc++     " 
checking "whether linker works"... "ok" 
checking "Native C++ compiler as"... "clang++ -m64 -fPIC -dynamic -fno-common -mmacosx-version-min=10.7 -stdlib=libc++ -Wno-deprecated-declarations " 
checking "Sequential C++ compiler as"... "clang++ -m64 -fPIC -dynamic -fno-common -mmacosx-version-min=10.7 -stdlib=libc++ -Wno-deprecated-declarations " 
checking "whether compiler accept -fno-stack-protector"... "ok" 
checking "whether C++ compiler supports C++11 without flags"... "yes" 
[...]
touch charm++
-------------------------------------------------
charm++ built successfully.
Next, try out a sample program like netlrts-darwin-x86_64-cxx1y.2/tests/charm++/simplearrayhello

#18 Updated by Jim Phillips about 2 years ago

Seems to have failed the auto-test. Will test after that passes.

#19 Updated by Jim Phillips about 2 years ago

The fix works. Thanks.

#20 Updated by Phil Miller about 2 years ago

  • Status changed from In Progress to Merged

#21 Updated by Jim Phillips about 2 years ago

When I pass OPTS_CXX="-gxx-name=g++44" to the build script it is preserved for future charmc invocations, which breaks on other machines.

#22 Updated by Phil Miller about 2 years ago

Jim, could you please elaborate?

#23 Updated by Sam White over 1 year ago

We need to update this for 6.9.0 and C++11 support. Our configure script points people to this issue if using ICC with old GCC headers.

#24 Updated by Jim Phillips over 1 year ago

Wanted to update with two alternative solutions, neither of which preserves the options in the build config files.

First, rather than trying to pass the -gcc-name and -gxx-name options via the Charm++ build script, they can be set via the __INTEL_PRE_CFLAGS environment variable:

setenv __INTEL_PRE_CFLAGS "-gcc-name=gcc44 -gxx-name=g++44" 

The modern way to install and access newer compilers is via the scl package (https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/):

scl enable devtoolset-6 -- ./build charm++ netlrts-linux-x86_64 ...

Also available in: Atom PDF