Visual Studio 2015 Update 3:

[AYee1]

On Visual Studio 2015 Update 3 with Intel Parallel Studio 2016 Update 3, including <intrin.h> while "__INTEL_COMPILER_USE_INTRINSIC_PROTOTYPES" is defined leads to the following error:

error : more than one instance of overloaded function "_mm_stream_load_si128" has "C" linkage

Step to Repro:

• Create a new project in Visual Studio 2015 Update 3.
• Set the compiler to Intel C++ 16.0.
• Add "__INTEL_COMPILER_USE_INTRINSIC_PROTOTYPES" to the preprocessor definitions.
• Compile the following code.

#include <intrin.h>

int main(){
}

It seems that Visual Studio has changed the definition of "_mm_stream_load_si128()" to take a const pointer instead of non-const.

[Melanie_B_Intel]

Yes I can reproduce this problem, thank you for reporting it.

I opened DPD200413238 in our internal defect tracking system.

--Melanie

[TimP]

I don't find adequate information on what might motivate you to set that macro, but I see that the problem is avoided by substituting #include <immintrin.h>.  Nor do I find in a cursory search advice on which of those header files is meant to be supported currently in CL or ICL.

This article

https://software.intel.com/en-us/articles/visual-studio-intellisense-stopped-recognizing-many-of-the-avx-avx2-intrinsics

makes yet a different selection of header file than you or I would do.

There is wording there which seems to indicate (contrary to examples) that the macro might be used in place of a header file inclusion, but is intended only to speed up compilation for AVX512.

[AYee1]

Tim P. wrote:

I don't find adequate information on what might motivate you to set that macro, but I see that the problem is avoided by substituting #include <immintrin.h>.

That macro was set for only one purpose - to keep Intellisense happy. The obvious work-around is to unset it. Then it will compile fine.

This came up while test-driving VS2015 Update 3 on a project that had a mix of SIMD intrinsics from all generations including MS-specific intrinsics which are normally found in <intrin.h>. So both <intrin.h> and <immintrin.h> are present.