Project

General

Profile

Bug #1149

Cray CC builds are broken

Added by Sam White about 3 years ago. Updated over 2 years ago.

Status:
Merged
Priority:
Normal
Assignee:
Category:
Build & Test Automation
Target version:
Start date:
07/22/2016
Due date:
% Done:

0%


Description

Build failure due to warning while testing C++11 options has been an issue for quite some time, especially since it fails without much information.

Proposed fix: continue compiling even if there are warnings (by setting the flag '-h msglevel_4'), with an additional message to the user about ignoring warnings.


Related issues

Related to Charm++ - Bug #1404: Support Cray CC on {mpi,gni}-crayxe Merged 02/08/2017

History

#1 Updated by Sam White almost 3 years ago

Cray CC 8.5 doesn't build even with the warnings turned off. Nikhil found a hack to make it work:

Apparently, telling craycc to turns off any warning does not prevent one of the warnings. Cleaner fixes will be hard to come by to work around Cray compiler's erratic behavior; here is a hack to enable Charm compilation (tested on Edison)

Apply this patch:

diff --git a/src/conv-core/converse.h b/src/conv-core/converse.h
index 542b41c..7d4099f 100644
--- a/src/conv-core/converse.h
+++ b/src/conv-core/converse.h
@@ -588,11 +588,11 @@ typedef CMK_TYPEDEF_INT8      CmiInt8;
 typedef CMK_TYPEDEF_UINT2     CmiUInt2;
 typedef CMK_TYPEDEF_UINT4     CmiUInt4;
 typedef CMK_TYPEDEF_UINT8     CmiUInt8;
-#if CMK___int128_t_DEFINED
+#if 0 && CMK___int128_t_DEFINED
 typedef __int128_t            CmiInt16;
 typedef __uint128_t           CmiUInt16;
 #define CMK_HAS_INT16         1
-#elif CMK___int128_DEFINED
+#elif 0 && CMK___int128_DEFINED
 typedef __int128              CmiInt16;
 typedef __uint128     CmiUInt16;
 #define CMK_HAS_INT16         1

and build using:

OPTS_CXX="-h msglevel_4 -h nomessage=11709" ./build charm++ gni-crayxc smp --with-production

#2 Updated by Phil Miller almost 3 years ago

For the int128_t crap, this is easier and cleaner:

diff --git a/src/scripts/configure b/src/scripts/configure
index c4082da..7543c20 100755
--- a/src/scripts/configure
+++ b/src/scripts/configure
@@ -2783,6 +2783,7 @@ cat > $t <<EOT
 int foo(void) {
   __int128_t   a;
   __uint128_t   b;
+  a = a + a;
   int x[(int)(sizeof(__int128_t) - 15)]={0};
   return x[0];
 }
diff --git a/src/scripts/configure.in b/src/scripts/configure.in
index a14f1e0..7a20c10 100644
--- a/src/scripts/configure.in
+++ b/src/scripts/configure.in
@@ -821,6 +821,7 @@ cat > $t <<EOT
 int foo(void) {
   __int128_t   a;
   __uint128_t   b;
+  a = a + a;
   int x[[(int)(sizeof(__int128_t) - 15)]]={0};
   return x[[0]];
 }

#3 Updated by Phil Miller almost 3 years ago

Even with that patch to configure, I still get consistent but inscrutable build failures in early object files, while Nikhil did not. If we actually care to support Cray CC, it'll take more investigation.

#4 Updated by Sam White almost 3 years ago

Improve configure test for 128-bit integers so that it fails correctly for CCE: https://charm.cs.illinois.edu/gerrit/#/c/1347/

#5 Updated by Jim Phillips almost 3 years ago

Sitting with someone from Cray now. Is there a reason this isn't committed yet?

#6 Updated by Sam White almost 3 years ago

Talk to Phil if you need specifics now but there are a couple patches related to this in gerrit review (authored by him) currently. I believe there are other problems though I'm not sure what they are.

#7 Updated by Jim Phillips almost 3 years ago

I'm also getting this trying to build with Cray compilers:

checking "whether C++ compiler supports C++11 without flags"... "no" 
checking "whether C++ compiler supports C++11 with '-std=c++0x'"... "no" 
checking "whether C++ compiler supports C++11 with '-qlanglvl=extended0x'"... "no" 
checking "whether C++ compiler supports C++11 with '--c++11'"... "no" 
checking "whether C++ compiler supports C++11 with '-h std=c++11'"... "yes" 
Charm++ requires some C++11 support, but doesn't know the flag to enable it

Looks like a simple logic error in the script.

#8 Updated by Eric Bohm almost 3 years ago

  • Assignee set to Juan Galvez

#9 Updated by Juan Galvez almost 3 years ago

Trying to build charm++ on Blue Waters with cray compiler

Trying to explicitly use craycc compiler as part of build options results in this:
"Selected Compiler: craycc
Inserted explicit compiler options on Cray systems. Use compiler wrappers by loading PrgEnv-*
e.g.) module load PrgEnv-* (e.g. gnu for gcc, intel for icc, and pgi for pgcc)
./build charm++ gni-crayxe <other build options>
Charm++ uses the compiler wrapper 'CC' specified by the Cray system. Don't use explicit compiler options on Cray systems."

If I omit craycc, build starts but configure script fails due to warnings issued by craycc during configure tests.
Building with the following line supresses warning messages and allows configure to pass:

OPTS_CXX="-h msglevel_4 -h nomessage=11709" ./build charm++ gni-crayxe smp --with-production

The next problem I run into is that the charmc script at various points uses g++ for compilation and linking instead of CC. Not sure exactly the causes or how to fix this properly, but I think is mainly related to charmc receiving the -host option, which enables the variable NATIVE in the charmc script which by whatever reason forces g++ instead of CC.

For now I manually hacked the charmc script to force CC instead of g++...

Now, building with

OPTS_CXX="-h msglevel_4 -h nomessage=11709" ./build charm++ gni-crayxe smp --with-production

charmxi apparently builds and links correctly. The first error I get is this:

gmake[1]: Leaving directory `/mnt/a/u/sciteam/galvez/charm-craycc-test/gni-crayxe-smp/tmp'
touch basics
Performing '/usr/bin/gmake charm++ OPTS=-optimize -production QUIET=' in gni-crayxe-smp/tmp
../bin/charmc  -optimize -production   -I.   -c -o DummyLB.o DummyLB.C
CC-940 crayc++: WARNING File = ckarrayindex.h, Line = 391
  A "return" statement is missing from the end of a non-void function
          "ck::FixedArrayIndexCompressor::decompress".

      }
      ^

Cray C++ : Version 8.4.6 (20160328193024_838fea6bbef776e483380a4ecf458b3dff303cd0)
Total warnings detected in DummyLB.C: 1
../bin/charmc  -optimize -production   -o ../lib/libmoduleDummyLB.a DummyLB.o 
ar: creating ../lib/libmoduleDummyLB.a
../bin/charmc  -optimize -production   -I.   -c -o GreedyLB.o GreedyLB.C
CC-311 crayc++: ERROR File = /opt/cray/cce/8.4.6/CC/x86-64/compiler_include_base/basic/intrinsics.h, Line = 273
  An overload function cannot be distinguished by the return type alone.

  extern int64_t _popcnt32(uint32_t);
                 ^

CC-940 crayc++: WARNING File = ckarrayindex.h, Line = 391
  A "return" statement is missing from the end of a non-void function
          "ck::FixedArrayIndexCompressor::decompress".

      }
      ^

Total warnings detected in GreedyLB.C: 1
Total errors detected in GreedyLB.C: 1
Fatal Error by charmc in directory /u/sciteam/galvez/charm-craycc-test/gni-crayxe-smp/tmp
   Command CC -I../bin/../include -D__CHARMC__=1 -I. -O2 -U_FORTIFY_SOURCE -h std=c++11 -c GreedyLB.C -o GreedyLB.o returned error code 1
charmc exiting...
gmake: *** [GreedyLB.o] Error 1
-------------------------------------------------
Charm++ NOT BUILT. Either cd into gni-crayxe-smp/tmp and try
to resolve the problems yourself, visit
http://charm.cs.illinois.edu/
for more information. Otherwise, email the developers at charm@cs.illinois.edu

#10 Updated by Juan Galvez almost 3 years ago

  • Status changed from New to In Progress

#11 Updated by Phil Miller over 2 years ago

I have a partial patch from Cray staff that improves the situation, that I'll clean up and integrate when I get time. They also said there will be fixes in their compiler resulting from the attempt. Maybe reassign this to me?

#12 Updated by Juan Galvez over 2 years ago

  • Assignee changed from Juan Galvez to Phil Miller

Ok, reassigned to Phil.

Building on Blue Waters I had other troubles which are documented above, and which are unrelated to the craycc compiler. Don't know enough about charmc to know why this was happening (maybe I just failed to pass the correct build options?). I manually got around those problems and then encountered compilation problems with craycc, which hopefully the patch from Cray solves.

#13 Updated by Phil Miller over 2 years ago

  • Status changed from In Progress to Implemented

Fixes on our side merged here:
https://charm.cs.illinois.edu/gerrit/2055

This needs Cray CCE version 8.5.5 or later to actually compile, though. None of the systems we have access to have that installed yet, so waiting on the Cray staff to report all's well before closing.

#14 Updated by Sam White over 2 years ago

That commit says cce 8.5.4, not sure if that is available anywhere or not...

#15 Updated by Sam White over 2 years ago

Blue Waters has cce/8.5.5 now (Edison still doesn't). I copied over gni-crayxc/conv-mach.sh to gni-crayxe/ and tried to build Charm, but got a build error in GreedyLB.C:

CC-311 crayc++: ERROR File = /opt/cray/cce/8.5.5/CC/x86-64/compiler_include_base/basic/intrinsics.h, Line = 273
  An overload function cannot be distinguished by the return type alone.
  extern int64_t _popcnt32(uint32_t);

We also get a million warnings like this and others that seem like nonsense:

CC-7212 crayc++: WARNING File = ../../../opt/gcc/4.8.1/snos/include/g++/tuple, Line = 1075
  Variable "@CFE_7_17019" is used before it is defined.

#16 Updated by Phil Miller over 2 years ago

The issue with intrinsics.h should be fixed by https://charm.cs.illinois.edu/gerrit/#/c/2140/ (deleting its inclusion entirely - it's old junk, referring to something else entirely, at this point.

#17 Updated by Sam White over 2 years ago

This now works if you build with 'craycc' specified explicitly as an option to build. In order for that to work you have to remove the check against explicit compilers on Cray builds that was added for issue #1110 in redmine.

Ideally you shouldn't need to specify craycc explicitly for this, and the changes to conv-mach should be duplicated for crayxe builds.

#18 Updated by Phil Miller over 2 years ago

  • Status changed from Implemented to Merged
  • translation missing: en.field_closed_date set to 2017-02-21 12:29:53.395212

Corresponding fixes for XE systems in bug #1404 here:
https://charm.cs.illinois.edu/gerrit/#/c/2252/

Seems like all else has been resolved, since we've tested cleanly on XE and XC. So, closing.

Also available in: Atom PDF