Intel C++ Composer XE 2013 SP1 Update 2 with VS 2010 problem

Intel C++ Composer XE 2013 SP1 Update 2 with VS 2010 problem

OS: Windows 8.1 x64

IDE: MS VS 2010

Downloaded and installed Intel C++ Composer XE 2013 SP1 Update 2, Version 2013.1.2.176.

Was previously using Intel C++ Composer XE 2013 SP1 Update 1 for Windows

with no issues.

After upgrade, Intellisense red underlines the includes for 

#include <mkl.h>
#include <mkl_rci.h>
#include <mkl_types.h>
#include <mkl_service.h>

and reports that "cannot open source mkl.h", etc. for all four mkl header files.

Also no option available to switch between MS and Intel compilers.

Please advise.

 

10 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

In my case, attempting to use the option to update by replacing update 1 led to failure.  By the time I realized that I needed to remove all the Intel compilers and start over, I also had to remove VS, remove all Intel entries from the Windows environment variables, and start over from the beginning.  It could be that the list of stale environment variable entries was responsible for the string of problems.

That is the reason for not to upgrade.If it is not broken do not fix it.

I already found one bug which is fixed in C++ update 2, so now -O3 is reliable in my tests, even with Cilk(tm) Plus.

I have a problem with VTune integration which crashes VS 2013 during the debugging,but I am still reluctant to upgrade.

@iliyapolak
 

Sun, 02/16/2014 - 04:48

 

"That is the reason for not to upgrade.If it is not broken do not fix it."

There is something to be said for this point of view ;-)

Anyways, after some experimentation I was able to resolve the issue:

Running "Repair" did not work, however, selecting "Modify" and explicitly selecting the settings including incorporate with MS VS 2010 solved the problem.

Not sure why I had to do this, but it did the trick.

Thanks for everyone's replies

Regards, 

A.

I just got around to reading the release announcement, indicating there is new added support for windows 8.1.  I'm giving up and going back to update 1, as VS2012 installation breaks after installing ICL update 2 and restarting.  Better to ignore win8.1 than to do special things to break it.  The update seemed to work fine on win7.

There must be more people downloading multiple versions than the download server administrators planned for.  It's about a 4 hour download here in the USA.  Meanwhile I can remove and reinstall VS and service packs.

The update 2 has fixed several issues related to VS2013 support in the Intel C++ Composer XE pkg. So it's a good idea to upgrade.

But when upgrading, make sure the "path" env-var is not over-flowed. Clean it after the installation and make sure the proper directories are added.

>> and reports that "cannot open source mkl.h", etc. for all four mkl header files.

Check the "Intel Performance Libaries" tab in the project property to be sure "Yes" is set for the "Use Intel MKL".

Jennifer

So we shouldn't use the update 2 on win8.1 unless we have VS2013?

I'm concerned about the consequences of the 90-day trial of VS2013 when my VS2012 pro is only 4 months old.

I should have learned my lesson about trying to install ICL other than by download manager, after spending another 6 hours on it today.

 I think I'm back to a working update 1 installation, without the wrongly ordered PATH entries produced by running update 2 with multiple Intel software tools.  But I'm still seeing problems with the visual studio developer command prompt, so I suppose ICL may still not work after reboot.

The persistent problem in the Windows 8.1 installation:

icl: error #10114: Microsoft Visual C++ not found in path

Apparently, the working of the Microsoft vcvars .bat file breaks and the PATH entry is lost.

I can add the VC\bin\amd64 entry to PATH myself, and get one step beyond the error quoted above; then

C:\PROGRA~2\Intel\COMPOS~1\compiler\include\omp.h(119): catastrophic error: cannot open source file "stdlib.h"
  #   include <stdlib.h>

So it seems that ICL can find its own include files but not those from Visual Studio, even if I add the VS path to INCLUDE environment variable.

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi