icl and cl conflict with cygwin usage

[Morgan_L_]

I realize that Cygwin is not a supported environment, but for various reasons some of us need to use it.

I am nominally using VS2015/Ifort 2015/icl 2015 and it works fine.

But, when I build the same source using the same compilers under Cygwin I get a lot of error messages.  The source is solid and compiles perfectly with either icl or cl under VS.  But, under Cygwin it seems to be confused. 

Using icl it seems to try and find VS include files. 

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(550): error: identifier "__is_assignable" is undefined                        : integral_constant<bool, __is_assignable(_To, _From)>

Using cl it throws the error:

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

Each code points to the other guy as the problem.  I suspect that it is something in the batch files that are invoked from the Intel command prompt that sets the intel environment that is subsequently processed by Cygwin.  I would appreciate any guidance for resolving this problem.

[JenniferJ]

how are you setting the compiler env?

if you open the build env from start-menu > programs..... > build env for Intel 64 in VS2015, and from this cmd window, set the Cygwin, it might work.

Jennifer

[TimP]

As Jennifer said, check whether the compilers are working in the cmd window before setting up cygwin. My CL has broken in the same way, possibly as a result of another broken Microsoft automatic update.  If you look in your file system, you should see float.h in \Windows Kits\10\Include\10.0.10240.0\ucrt\.  I'm hoping that running Repair from Programs and Features may fix this (again).  2016u3 and the beta compilers work with VS2015u2, with or without cygwin (with the use of -Qlocation,link to set the path to the VS2015 VC folder (AMD64 if using Intel64).

ICL 2015u4 worked with the VS2015 full release, which required a fresh installation if you had a pre-release VS2015.  ICL 2015u5 worked with VS2015.1.   Microsoft apparently wants you to take the VS updates or reinstall from scratch if updates break.

[Morgan_L_]

Thanks for the posts.  Yes, as Jennifer says I am using the Intel command window to set he environment before going into Cygwin.  It executes an Intel script passing arguments for intel64 and vs2015.  When I which ifort, icl, msvc, and link inside Cygwin they are all there.  The problem isn't with the compilers - it is with the include files, or at least how the include files are being set up for use under Cygwin.  The supplied Intel scripts work properly for Intel 12 and 16, but not 15.  The problem it that some of our users only have access to 15.  We need a stable solution.

The only solution I can see is to set up clean environments on diverse PCs - 1 for 2015 and 1 for 2016 and then inside Cygwin look for what is different between the included files and then try to diagnose what is wrong with the 2015 scripts.  I was hoping that someone had already found the answer.

[TimP]

I don't see how you can expect to use older Intel compilers with VS2015.  I'm still running a repair on VS2015 which I started several hours ago, which should fix the problem with CL using older paths for its own include files.  I don't think you can expect cygwin bash etc. or mintty shells to work with respect to include paths internal to CL.

I verified on my Windows 8.1 installation that an up to date VS2015.2 installation doesn't see this problem with use of obsolete paths to includes etc. but still it's not compatible with the current ICL 2015.  My Windows 10 seems to have rolled back to a broken VS2015 as a consequence of enrolling and then withdrawing from Insider Previews.

I'd have doubts anyway about whether ICL 2015 would take advantage of new features in VS2015 which aren't present in VS2013.
 

[Morgan_L_]

When I use Intel 12 I use VS 2010 with it - not VS 2015.

[TimP]

OK, I have isolated the problem on my Windows 10 system, according to the following steps:

1.  Open the VS2015.2 X64 native cmd window.  CL works here.

1a: add the cygwin environment in the VS2015 X64 window.  CL still works, as far as INCLUDE is concerned.

 "set INCLUDE" should show you that Windows Kits include\10.0.10240.0\ucrt is where float.h will be found.

2. Open the PSxe2015u7/VS2015 cmd window.  CL shows the problem of looking in wrong paths.

"set INCLUDE" shows that the obsolete Visual Studio 14.0\VC\INCLUDE (as well as ICL folders) is searched prior to the correct Microsoft paths.

3.  Open PSxs2016u3/VS2015 cmd window.  "set INCLUDE" shows that the obsoleted INCLUDE folder isn't in the search path. So Intel did get this right in that release, which was the first to support VS2015.2.

This is not to say that correcting the breakage of VS2015.2 INCLUDE path which is introduced by the ICL 2015 setup would be sufficient to make ICL and CL work as it does in the ICL 2016u3 and 2017 beta tests.  You should look at least to see whether a similar problem comes up in LIB path.

Anyway, I am satisfied that cygwin is not responsible for INCLUDE breakage.  I did have quite a hassle re-introducing the Qlocation,link options to assure that the Intel compilers use the VS2015 VC\bin\amd64 folder (which works with VS2013 as well).

You may have compelling reasons for wishing to see this breakage corrected for the combination of ICL2015 and VS2015, although for myself I am satisfied to use PSxe2015 with VS2013 and PSxe2016 with VS2015.  If so, you might open an IPS support ticket.  I suspect that Intel may give PSxe2015 an end-of-life (within 5 months), so I would be more interested in asking to fix any deficiencies in PSxe2017.

[TimP]

Now it has been confirmed that the developers know psxe2015u7 doesn't work with current VS2015:

https://software.intel.com/en-us/forums/intel-c-compiler/topic/638739

So it appears that maintenance to deal with Microsoft updates has already been discontinued.

To me, it's misleading and a waste of customers' time for the release notes to be issued without a correction to indicate that VS2015 support was dropped prior to update release, and for the install to indicate that VS2015 integration is available and was accomplished.

I had no difficulty running ifort xe2015 in the VS2015 integration cmd prompt window, but the point of that setup is to support C interoperability.

[Melanie_B_Intel]

Sometimes I use icl with cygwin. I use iclvars.bat and then I start cygwin.  (e.g. when I'm testing boost with the Intel compiler)

Both cl.exe and icl.exe use the INCLUDE environment variable to determine the include search path.  The Intel setting of the INCLUDE directory puts Intel include directories in front of the Visual Studio directories, and that causes problems for some of the include files, e.g. you noticed a problem with float.h

I've noticed that in the boost build and regression testing methodology, the "iclvars.bat" or "vcvars.bat", (for icl.exe and cl.exe respectively) are invoked before each compiler invocation.  You might try that in your build system.

--Melanie

[TimP]

The point here is that iclvars prepends an obsolete Microsoft folder as well as the Intel folders to the INCLUDE path.  You might get somewhere by removing the folder which shouldn't be on INCLUDE path, as the current one was added later by vcvars.bat (or copying the correct one over the old one).  However, there appear to be other disabling conflicts between VS2015.2 and ICL 2015u7, including those which were a problem in ICL 2016u2 which had workaround suggestions on this forum.

[Morgan_L_]

Tim and Melanie,

Thanks for your input.  I will probably build a test machine and environment this weekend (W7, VS2015, Intel 2015, cygwin64) and try these suggestions.  It is looking like changes to the .bat files may be the solution because I want it to work each time I do a Cygwin build and I need a solution that can be "ported" to other people that are working with this code.  The other reason I need a test region is to separate my problems.  Another problem is that I discovered that the Cygwin build does a static link that makes an .exe that works in W7, W10 and on machines with no VS installed.  The VS installs do not.  They are missing CRT libs, openMP libs [this code is threaded up the wahzoo], stray dll-s, etc.  So I also need a machine with virgin W7 and W10 that I can throw .exe-s at to see if the VS linking problems are resolved.

I'll keep this alive until I get it resolved - thanks ever so much.

[Melanie_B_Intel]

Hopefully you could use ICL2016update3, i.e. the latest publicly available Intel compiler. That would be the best bet for working with vs2015 [until we release our next compiler!].  Good luck.

[TimP]

You may be referring to use of the mingw "cross compilers" under cygwin.  "cygwin native" compilation links against several dlls, including the very large cygwin1.dll for posix support, and puts your source code under GPL license if you distribute your application. mingw with minimal options other than -static may do what you say.   Either way, the setup we have been discussing won't interfere with use of Visual Studio compatible compilers.

Level of OpenMP support may be relevant to you, although not if you are preserving compatibility with Microsoft CL.  CL has stayed at OpenMP 2.0 for years. Windows 10 Insider Preview offers a linux subsystem with gcc and OpenMP 3.1.  ICL 2015 and the pre-built compilers in Cygwin are OpenMP 4.0 (gcc ignores more of OpenMP 4 on Windows than on linux).  ICL 2016u3 has partial OpenMP 4.5, and ICL 2017 beta u1 seems to claim full OpenMP 4.5.  I haven't looked to see if mingw has an option to run without OpenMP library dll, unlike ICL and cygwin.

Intel libiomp5.dll supports all OpenMP calls from CL with improved performance, but not Windows gcc OpenMP calls.

[Morgan_L_]

Melanie - thanks, but the issue is more complex.  The code I am using is validated to run under certain conditions and with certain toolsets with an international community of users and Intel 2015 is the current environment - and we need to fix whatever is wrong.  The previous environment used 2012.

Tim - in fact under Cygwin I do not use the ming compilers.  I found that mingw64 compiles but then coughs up blood if openMP is used (preprocessor directives are used to select this option).  In my builds ifort and icl or ifort and msvc are used.

Thank you both for your posts.

[TimP]

Unfortunately, it's somewhat contradictory if your "international community of users" insists on such a new version of Visual Studio combined with an Intel compiler version which is nearly off support and hasn't kept up with the latest Microsoft releases.

As we've discussed, although Intel doesn't support use of cygwin as a development environment for Windows target, it appears you have stayed within the limits of what normally works (but in no way compensates for problems between Intel and Microsoft releases).

In the sequence of compilers which are likely to be available in mingw, the combination of options -fopenmp -ffast-math is particularly unreliable, as was the gcc 5.1 for mingw.  In view of this and that gcc Windows doesn't officially nor fully support OpenMP, and there are multiple mingw versions available which don't have the support of gcc community, it probably wouldn't be appropriate for your "community" to adopt such combinations in preference to a stable combination of VS and ICL.