Modify

Opened 12 months ago

Last modified 5 months ago

#2115 new defect

supermike II fails to compile

Reported by: Roland Haas Owned by:
Priority: minor Milestone:
Component: SimFactory Version: development version
Keywords: Cc:

Description

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;
    ^

Attachments (0)

Change History (8)

comment:1 Changed 11 months ago 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.

comment:2 Changed 11 months ago 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;


comment:3 Changed 11 months ago by zachetie@…

Found the offending commit!

commit f9cbab7bd3fd534fec2d254665ce6228f6f3ef71
Author: Erik Schnetter <schnetter@…>
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@…>
Date: Mon Aug 21 16:28:53 2017 -0400

Vectors: New configure flags VECTORISE_ALIGN_FOR_CACHE and VECTORISE_ALIGN_INTERIOR

... works just fine.

comment:4 Changed 11 months ago by Steven R. Brandt

Does that mean we have a fix?

comment:5 Changed 10 months ago by Roland Haas

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.

comment:6 Changed 10 months ago by Roland Haas

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).

comment:7 Changed 10 months ago 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.

comment:8 Changed 5 months ago 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?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
Next status will be 'confirmed'.
The owner will be changed from (none) to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.