supermike II fails to compile

Create issue
Issue #2115 new
Roland Haas created an issue

The current simfactory files fail to compile the ET on SuperMike II at LSU HPC. One gets:

In file included from /home/rhaas/ET_vanilla/arrangements/CactusUtils/Vectors/src/vectors.cc(1):
/home/rhaas/ET_vanilla/arrangements/CactusUtils/Vectors/src/vectors.h(877): error: invalid type for defaulted constructor
    vmask(vmask &&) = default;
    ^

Keyword:

Comments (9)

  1. Zach Etienne
    • removed comment

    This error also occurs on WVU's Spruce Knob resource.

    Using icc --version icc (ICC) 17.0.1 20161005 Copyright (C) 1985-2016 Intel Corporation. All rights reserved.

  2. Zach Etienne
    • removed comment

    Similar error using icc --version icc (ICC) 15.0.2 20150121 Copyright (C) 1985-2015 Intel Corporation. All rights reserved.

    My guess at this point is that whoever originally committed this was using a really new Intel compiler.

    Start list of compile errors:

    .../Cactus/arrangements/CactusUtils/Vectors/src/vectors.h(877): error: invalid type for defaulted constructor vmask(vmask &&) = default; ^

    In file included from .../Cactus/arrangements/CactusUtils/Vectors/src/test.cc(1): .../Cactus/arrangements/CactusUtils/Vectors/src/vectors.h(879): error: invalid type for defaulted assignment operator vmask &operator=(vmask &&) = default; ^

    In file included from .../Cactus/arrangements/CactusUtils/Vectors/src/vectors.cc(1): .../Cactus/arrangements/CactusUtils/Vectors/src/vectors.h(877): error: invalid type for defaulted constructor vmask(vmask &&) = default; ^

    In file included from .../Cactus/arrangements/CactusUtils/Vectors/src/vectors.cc(1): .../Cactus/arrangements/CactusUtils/Vectors/src/vectors.h(879): error: invalid type for defaulted assignment operator vmask &operator=(vmask &&) = default; ^

  3. Zach Etienne
    • removed comment

    Found the offending commit!

    commit f9cbab7bd3fd534fec2d254665ce6228f6f3ef71 Author: Erik Schnetter schnetter@gmail.com Date: Tue Aug 22 09:08:37 2017 -0400

    Vectors: Provide vectorized reduction operators
    

    ... is the first commit that yields the compiler error.

    Therefore commit

    commit 7b68551394d3748044362f47ac03d44ad7aede89 Author: Erik Schnetter schnetter@gmail.com Date: Mon Aug 21 16:28:53 2017 -0400

    Vectors: New configure flags VECTORISE_ALIGN_FOR_CACHE and VECTORISE_ALIGN_INTERIOR
    

    ... works just fine.

  4. Roland Haas reporter
    • removed comment

    No, I would not immediately say that. The code added in that commit uses (as far as I know) only C++11 and we list C++11 (at least as subset of it) as a requirement for the ET. The compiler used on supermike II defaults to use the Intel 13 compiler which is very old by now and while we request gnu++11 that particular compiler does not yet handle defaulted move constructors correctly (see https://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler in particular http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3053.html looks like it might be the only applicable but I am by no means sure given the complexity of the language in the proposals).

    I think I tried to use newer compilers for a bit on supermike II and had no luck either though. I mostly dropped my efforts when realizing that I had confused supermike II and supermic (the former being LSU - HPC only while the latter is currently accessible through XSEDE).

    We need / want to keep some of the commit f9cbab7bd3fd534fec2d254665ce6228f6f3ef71 namely the part that introduces the vectorized reduction operators. If that part can be nicely separated from the part that makes old compilers quit and if the part that makes compilers quit is not deemed to be performance relevant then we could / should / may want to remove only those bits.

  5. Roland Haas reporter
    • removed comment

    It also seems to work just fine with the intel 14 / 15 compiler on other clusters. So it would be good to find out why it fails on Spruce Knob and supermike II but works eg on queenbee (Intel 14) or cori (intel 15).

  6. Zach Etienne
    • removed comment

    I have confirmed the issue appears with Intel 17.0.1 (20161005) on Spruce as well, which runs RHEL6 (Linux kernel 2.6.32-696.1.1.el6.x86_64). Note that CXXFLAGS are set to use C++11:

    CXXFLAGS = -Ofast -qopenmp -xHost -align -std=c++11

    Given what Roland has found, my suspicion at the moment is that this is not a compiler issue.

  7. Zach Etienne
    • removed comment

    I found a fix! It turns out that the struct that is triggering the compilation errors on Intel 17.0.1 (and 15.0.2) on RHEL6 is never used except by functions that are never called:

    vstore_masked() and vstorea_masked()

    I commented out the vmask and vstore()/vstorea() declarations and the Vectors thorn (as well as the rest of the Toolkit) compiled just fine.

    Doesn't this mean that the vmask struct, vstore_masked(), and vstorea_masked() are dead code and should be removed?

  8. Roland Haas reporter

    The functions vstore_masked() and vstorea_masked() are used in HydroOpenMPToy. Right now the mike.ini file in simfactory uses shelob-mvapich.cfg to build which uses parallel_studio_xe_2018.0 to compile which is Intel 18.0 and which seems to work fine (on shelob). My suspicion (with anything Intel compiler and C++ related) is that there is an incompatible version of g++ (and its C++ library) being used with Intel 17 (see https://software.intel.com/en-us/articles/intel-c-compiler-170-for-linux-release-notes-for-intel-parallel-studio-xe-2017). Intel 17 supports gcc versions 4.3 - 6 .

  9. Log in to comment