Fails with Intel compiler in C++11 mode

[mrzv]

The following simplest example:

#include "variant.hpp"

int main()
{
    using MyVariant = mpark::variant<int, float>;
    MyVariant x = 5;
}

fails to compile with the Intel compiler if I pass it -std=c++11, but compiles fine, if I give it -std=c++14. It compiles in C++11 mode with GCC and Clang.

The compiler version is:

icpc (ICC) 18.0.1 20171018
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

The error it reports:

In file included from example.cpp(1):
variant.hpp(995): warning #3801: deduced return types are a C++14 feature
          inline static constexpr auto &&get_alt(V &&v, in_place_index_t<0>) {
                                  ^

In file included from example.cpp(1):
variant.hpp(1000): warning #3801: deduced return types are a C++14 feature
          inline static constexpr auto &&get_alt(V &&v, in_place_index_t<I>) {
                                  ^

In file included from example.cpp(1):
variant.hpp(1026): warning #3801: deduced return types are a C++14 feature
          inline static constexpr AUTO_REFREF get_alt(V &&v)
                                  ^

In file included from example.cpp(1):
variant.hpp(1033): warning #3801: deduced return types are a C++14 feature
          inline static constexpr AUTO_REFREF get_alt(V &&v)
                                  ^

In file included from example.cpp(1):
variant.hpp(1076): error: expected an identifier
              inline static constexpr DECLTYPE_AUTO dispatch(F f, Vs... vs)
                                      ^

In file included from example.cpp(1):
variant.hpp(1076): error: "auto" is not allowed here
              inline static constexpr DECLTYPE_AUTO dispatch(F f, Vs... vs)
                                      ^

In file included from example.cpp(1):
variant.hpp(1076): error #303: explicit type is missing ("int" assumed)
              inline static constexpr DECLTYPE_AUTO dispatch(F f, Vs... vs)
                                      ^

In file included from example.cpp(1):
variant.hpp(1076): error: expected a ";"
              inline static constexpr DECLTYPE_AUTO dispatch(F f, Vs... vs)
                                                    ^

In file included from example.cpp(1):
variant.hpp(1080): warning #12: parsing restarts here after previous syntax error
            };
            ^

In file included from example.cpp(1):
variant.hpp(1084): warning #3801: deduced return types are a C++14 feature
          inline static constexpr AUTO make_dispatch(lib::index_sequence<Is...>)
                                  ^

In file included from example.cpp(1):
variant.hpp(1088): warning #3801: deduced return types are a C++14 feature
          inline static constexpr AUTO make_fdiagonal_impl()


[...]


In file included from example.cpp(1):
variant.hpp(2341): error: expected a ";"
    inline constexpr DECLTYPE_AUTO visit(Visitor &&visitor, Vs &&... vs)
                                   ^

In file included from example.cpp(1):
variant.hpp(2381): warning #12: parsing restarts here after previous syntax error
      }  // namespace hash
      ^

In file included from example.cpp(1):
variant.hpp(2383): error: expected a declaration
    }  // namespace detail
    ^

In file included from example.cpp(1):
variant.hpp(2423): warning #12: parsing restarts here after previous syntax error
                      v);
                        ^

In file included from example.cpp(1):
variant.hpp(2424): error: expected a declaration
        return hash_combine(result, hash<std::size_t>{}(v.index()));
        ^

In file included from example.cpp(1):
variant.hpp(2425): error: expected a declaration
      }
      ^

In file included from example.cpp(1):
variant.hpp(2437): warning #12: parsing restarts here after previous syntax error
      };
       ^

In file included from example.cpp(1):
variant.hpp(2443): error: expected a declaration
    };
    ^

In file included from example.cpp(1):
variant.hpp(2446): error: hash is not a template
    struct hash<mpark::monostate> {
           ^

In file included from example.cpp(1):
variant.hpp(2455): error: expected a declaration
  }  // namespace std
  ^

example.cpp(7): warning #12: parsing restarts here after previous syntax error

compilation aborted for example.cpp (code 2)

[mpark]

@mrzv: My guess would be that this is for ICC running on Windows? Is that right?

[mrzv]

@mpark Nope, Linux.

[mpark]

Hm... I'm not able to repro it on Godbolt although the exact compiler version you mentioned isn't available on Godbolt. I'm testing with 18.0.0, 19.0.0 and 19.0.1.

Based on the error message you posted, the error seems to be that the conditional define for MPARK_RETURN_TYPE_DEDUCTION is evaluating to true when it shouldn't.
The condition is defined(__cpp_return_type_deduction) || defined(_MSC_VER), so unless __cpp_return_type_deduction is set incorrectly (I don't think this is the case...) or _MSC_VER is set because ICC is pretending to be MSVC.

Could you check if _MSC_VER is set under your config for some reason?

[mrzv]

Running the following input through the compiler

#ifdef _MSC_VER
#pragma message "MSC_VER"
#else
#pragma message "No MSC_VER"
#endif

#ifdef __cpp_return_type_deduction
#pragma message "__cpp_return_type_deduction"
#else
#pragma message "No __cpp_return_type_deduction"
#endif

prints

No MSC_VER
__cpp_return_type_deduction

[mrzv]

Ah, I figured it out. I've been doing all of this on a super-computer, which uses a module system. The GCC module is not loaded by default, but the Intel compiler relies on the GCC standard library to work correctly. Loading the gcc module fixes the problem. My bad; thanks for looking into it.

[mpark]

Ah.. interesting. So without the GCC module ICC defines __cpp_return_type_deduction under C++11 mode 🤔 that's odd. But okay, I'll close this.

[morrisonlevi]

@mrzv What supercomputer site is this? They probably need to set -gcc-name and such inside of their icpc.cfg file which corresponds to the requisite GCC version. This is important, as the Intel compilers definitely have restrictions on which gcc headers they'll work with.

This is unrelated to the issue, of course, but figured I'd leave it out in the open in case it is helpful.

[mrzv]

@morrisonlevi Thanks for the note. This all took place at NERSC. I'll pass this information on to their consultants.