VS2015.3

[TimP]

I'm curious as to how VS2015.3 will impact Intel Parallel Studio.  I doubt that I care about any new features, so of course the default course is to sit back and hope none of my working installations go bad.  Would future updates of Parallel Studio be tested against VS2015.3?

Apparently, unlike previous "upgrades," this update is not an involuntary push.  In order to get it, you open up the VS2015 modify/update and select update 3.   To begin to satisfy my curiosity, I'm trying it on my oldest box, where I can drop back to VS2013 if 2015 goes sour.  This may compound the confusion caused by Parallel Studio 2015 (the current most stable release) claiming support for VS2015 but not working after the VS2015.2 update, while psxe2016.3 and 2017 beta do support VS2015.2.

[TimP]

Both ICL and CL worked fine on my first test in the combined VS2015.3 and ICL 2017u1 beta environment.  In fact, CL showed several new cases of effective auto-vectorization even on Nehalem, sometimes out-performing ICL, even though it is only default SSE2.

ICL 2016u3 worked fine under VS2015.3, but CL didn't work with intrinsics in the ICL environment.  Following error is quoted:

You are using an Intel supplied intrinsic header file with a third-party compiler.
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\intrin.h(1051): error C2733: '_mm_stream_load_si128': second C linkage of overloaded function not allowed
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.3.207\windows\compiler\include\smmintrin.h(271): note: see declaration of '_mm_stream_load_si128'

On the Nehalem target, ICL 2016 vector code sometimes performs better than the 2017 beta.

Neither ICL nor CL are working in the ICL 2015u7 environment with V2015.2 or 2015.3.  CL fires the usual complaint:

C:\Program Files (x86)\Intel\Composer XE 2015\compiler\include\float.h(37): fatal error C1083: Cannot open include file: '../../vc/include/float.h': No such file or directory

which is due to PSXE2015 setting up the include path with that incorrect item (which was OK in VS2015.1).

I guess, since it is possible to work around the problem with CL intrinsics under PSXE2016 by opening up an environment without Intel compiler (as well as by using VS2013 or PSXE2017), I may put VS2015.3 on my other box.

[Melanie_B_Intel]

Tim, are you using the IDE to build your project? or the command line?  Is there a way you could customize the environment for your cl compilation to use the vcvars and thus avoid the problem with float.h and the issue with the intrinsic declaration?

[TimP]

Yes, the new CL works when opening a visual studio C++ cmd window, as well as under PSXE2017 beta u1.  Same problem with PSXE2016u3 CL intrinsics on a Windows 8.1 HSW and on a Windows 10 NHM installation.  The wrong path to float.h appears only in the PSXE2015 setup.  I noted today that I had an installation which claimed to be VS2015.1 which has had that problem since some kind of partial VS2015.2 updates have been around, but I told it to complete the VS2015.3 upgrade.  It also had a problem with requiring the skipping of the install menu update in order to proceed to the 2015.3 update.

I've hardly exhausted all the possibilities, but I've noticed that PSXE2015 is more stable (at run time) when building in the VS IDE than from command prompt, even after searching out options to make them as close as possible, including examining buildlog.  The Qip/ipo/Ob options don't seem to have consistent defaults as documented in any of the recent compilers, and there are also discrepancies about /Qprec-div and /Qftz defaults.  So I'm  in sympathy with those who want to stick with PSXE2015 as long as it seems the most stable one.