Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Visual Studio 2015 Update 3:

AYee1
Novice
766 Views

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.

0 Kudos
3 Replies
Melanie_B_Intel
Employee
767 Views

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

I opened DPD200413238 in our internal defect tracking system.

--Melanie

0 Kudos
TimP
Honored Contributor III
767 Views

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.

0 Kudos
AYee1
Novice
767 Views

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.

0 Kudos
Reply