mpark / variant

C++17 `std::variant` for C++11/14/17
https://mpark.github.io/variant
Boost Software License 1.0
659 stars 88 forks source link

Failure with Intel ICPC 19.1.3 on MacOS #77

Closed azukaitis closed 2 years ago

azukaitis commented 3 years ago

I am getting the following error following the examples on the Readme:

path/variant_example/3rdparty/variant/include/mpark/variant.hpp(1613): error: parameter pack "Ts" was referenced but not expanded
          typename Front = lib::type_pack_element_t<0, Ts...>,
                           ^

compilation aborted for path/variant_example/hello_world.cpp (code 2)
make[2]: *** [CMakeFiles/hello-world.dir/hello_world.cpp.o] Error 2
make[1]: *** [CMakeFiles/hello-world.dir/all] Error 2

The intel C++ compiler ties to the underlying apple-clang compiler and I can see that icpc is setting "clang".

cheddar:variant_example: $ icpc -dM -E -std=c++11 -x c++ -I 3rdparty/variant/include ./hello_world.cpp | grep -yR __clang__
(standard input):#define __clang__ 1
(standard input):#define __clang__ 1

I'm not sure if this is an Intel error or not since by default Intel ties to the underlying apple-clang C/C++ compiler.

Thanks for looking, Tony

sbolding-LANL commented 3 years ago

I am also looking at this with @azukaitis. For some reason icpc on MacOSX is incorrectly detecting __has_builtin(__type_pack_element)) as true, and then its frontend can't actually handle it as of intel 19.1.3. On Linux with an intel 19.0.4 that was built against GCC 7.4.0 where __has_builtin was not defined, this all works fine.

Replacing the check for type_pack_element to guard against intel is the minimal fix to get it running with intel 19 on Linux and Macs:

#if defined(__has_builtin(__type_pack_element)) && !(defined(__ICC)) 
#define MPARK_TYPE_PACK_ELEMENT
#endif

Maybe it makes sense to just disable __has_builtin for __ICC, but that throws a warning. I am not that familiar with how Intel depends on the underlying compiler used to build it, but I am guessing it is somehow forwarding along to the clang preprocessor and getting mistaken that it has __type_pack_element support.

We will try to check with the Intel compiler team first to see if there is something we can do to fix this with compiler flags (it won't let me just undefine __has_builtin from the command line), but otherwise it would be of interest to add something like the above to support older versions of Intel on Apple, and potentially with versions of GCC that have __has_builtin defined.

azukaitis commented 3 years ago

Confirmed what @sbolding-LANL found with the fix and it had nothing to do with clang.

sbolding-LANL commented 3 years ago

Heard back from Intel, and they are looking into it. This issue still exists with their new OneAPI compilers on MacOS.