#2115: supermike II fails to compile ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- 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; ^ }}}
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by zachetie@…):
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.
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by zachetie@…):
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; ^
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by zachetie@…):
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.
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by sbrandt):
Does that mean we have a fix?
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
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.
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
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).
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by sbrandt):
Why don't we just add a variable?
{{{ auto fresult = ftell(...) if(fresult < 0) { *filesize = 0; fprint(fstder,...) ... } else { *filesize = fresult; } }}}
#2115: supermike II fails to compile -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by zachetie@…):
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.
#2115: supermike II fails to compile --------------------------+--------------------------------- Reporter: Roland Haas | Owner: (none) Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Resolution: | Keywords: --------------------------+---------------------------------
Comment (by zachetie@…):
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**?
trac@lists.einsteintoolkit.org