Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Andre_N_
Beginner
447 Views

Intel Compiler 16 does not find "float.h" header in MSVC2015 mode.

Hi

While compiling the CppUTest library, I noticed, that the intel compiler does not find the correct "float.h" header for MSVC2015.

This is the error:
 

D:\Compiler\Intel\compilers_and_libraries_2016.0.110\windows\compiler\include\float.h(37): fatal error C1083: Datei (Include) kann nicht geöffnet werd
en: "../../vc/include/float.h": No such file or directory

 

I had a look at this float.h file from the intel compiler and saw there an assumption, where the intel compiler expects to find the float.h:

 

            /*
            // Here, the #include <../../vc/include/header.h> is used as the
            // equivalent of #include_next<header.h> working for MS C compiler
            // of MSVS 2005, 2008, 2010 with default installation paths.
            // The equivalent works correctly when Intel compiler header is not
            // located in ../../vc/include subfolder for any searched include path,
            // and MS header is.
            // In case of non standard location of MS headers, say in
            // C:/PROGRA~1/MSVS/NEW_VC/INCLUDE folder, proper __MS_VC_INSTALL_PATH
            // macro should be defined in command line -D option
            // like -D__MS_VC_INSTALL_PATH=C:/PROGRA~1/MSVS/NEW_VC.
            */
            #ifndef __MS_VC_INSTALL_PATH
            #define __MS_VC_INSTALL_PATH    ../../vc
            #endif

            #define __TMP_GLUE(a,b)         a##b
            #define __TMP_PASTE2(a,b)       __TMP_GLUE(a,b)
            #define __TMP_ANGLE_BRACKETS(x) <x>

            #include __TMP_ANGLE_BRACKETS(__TMP_PASTE2(__MS_VC_INSTALL_PATH,/include/float.h))

 

This assumption was correct for MSVC2013, but MSVC2015 does not have the "float.h" in "<install-dir>/vc/include" anymore.
The MSVC2015 version has the float.h in this path:
c:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\float.h

The path "c:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt" is already an include path for intel compiler, so a workaround is to simply change the intel float.h file to include the float from there:
 

        //#include __TMP_ANGLE_BRACKETS(__TMP_PASTE2(__MS_VC_INSTALL_PATH,/include/float.h))
	#include <../ucrt/float.h>

 

Maybe this hint is helpful for anyone.

Best regards,
André

0 Kudos
9 Replies
447 Views

Hi Andre,

I can NOT reproduce your issue. See below:

: type test.cpp
#include <float.h>
int main() {return 0;}
: icl test.cpp
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi
on 16.0.0.110 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

test.cpp
Microsoft (R) Incremental Linker Version 14.00.23026.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:test.exe
test.obj

:

I have no idea what is wrong in your machine, but if you read more on Intel compiler's float.h file:

#if (defined(_WIN32) || defined(_WIN64))
    /* Include_next should be before guard macros _FLOAT_H__ in order to at last reach system header */
    #ifdef __INTEL_COMPILER
        #include_next <float.h>     /* utilize system header */
    #else
        #if _MSC_VER >= 1400 /* Previous versions of MSVS are not supported. */

As __INTEL_COMPILER is always defined (in recent Intel compiler versions at least), the else part should never be used (it may exist for legacy reason? I have no idea...). the include_next is well supported and can find the headers on my machine (yes, you are correct that the part for 2015 is not in vc/include, it is in ucrt in windows SDK).

Whatever, it is great that you can make it work in your environment, but if you have interests, you may explore more and find the root cause and share more. :)

Thanks,

Shenghong

447 Views

FYI....And forgot to mention that, it can be reproduced when undef __INTEL_COMPILER, but this is not intended when using Intel compiler. Please make sure CppUTest will not do this, you may debug your float.h and check whether this compiler's internal macro is defined in float.h. Maybe some configuration undefined it...

: type test.cpp
#undef __INTEL_COMPILER
#include <float.h>
int main() {return 0;}
: icl test.cpp
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi
on 16.0.0.110 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

test.cpp
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.0.110\windows\c
ompiler\include\float.h(37): catastrophic error: cannot open source file "../../
vc/include/float.h"
              #include __TMP_ANGLE_BRACKETS(__TMP_PASTE2(__MS_VC_INSTALL_PATH,/i
nclude/float.h))

                ^

compilation aborted for test.cpp (code 4)

:

 

Andre_N_
Beginner
447 Views

Hi Shenghong,

thanks for your answer.
You are right, this was also my thought, so I defined "__INTEL_COMPILER" manually in my project but then the compiler complains about "#include_next" is an unsupported preprocessor definition.

I tried it now again and noticed, that the CMake makefiles took "cl" instead of "icl" as compiler. When I specify "icl" then everything works out of the box.

But what I don't understand: Why does the headers for the intel compiler have a fallback solution? Why not fail with a warning, if __INTEL_COMPILER is not set and say "Hey you are processing an Intel Compiler Header without using Intel Compiler... are you really using ICL and not CL?". This would be helpful :)

Ok, thanks for your help.

Best regards,
André

TimP
Black Belt
447 Views

This problem with C headers not being visible appears to be an issue with the on-line updating of VS2015, as discussed in an earlier thread.  The solution proposed by the Intel support person was to remove VS2015 (and Intel compiler) entirely and install the current version from scratch.

You can verify the situation by examining your INCLUDE environment setting to see whether it includes the latest installed Windows Kits\ucrt folder.  If not, a quick work-around is to copy the headers you want from the current Windows Kits\ucrt to the one which is on your INCLUDE.  There is an MSDN reference relating to a similar problem, but it doesn't cover this.

 

447 Views

Hi Andre,

Even I've noticed that when using MS compiler "cl" to build the code it will have this error. But sorry that I did not reply you timely yesterday as it was time to go home. :)

Now, it makes sense that you get this error, as MS compiler does not have __INTEL_COMPILER macro and in fact, MS compiler does not support include_next preprocessor.

I think the "#else" part in Intel compiler's float.h is used for MS compiler. But as VS2015 changed this locations, it failed with MS compiler.

We do have some warning message when using 3rd party compiler with Intel compiler's intrinsic headers, but for float.h, we do not have this warning (I guess it is because this header is compatible with 3rd party compiler??)

: cl test.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

test.cpp
You are using an Intel supplied intrinsic header file with a third-party compile
r.
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.0.110\windows\c
ompiler\include\float.h(37): fatal error C1083: Cannot open include file: '../..
/vc/include/float.h': No such file or directory

: type test.cpp
#include "xmmintrin.h" // for SSE

#include <float.h>
int main() {return 0;}
:

 Also, for this float.h, even a warning may not be enough, as we depends on MS compiler's float.h and need to include_next with it. If we need to block it, we have to report an error, that may be also an issue for users using "cl" in Intel compiler's environment (this is possible, right? for example: mix usage of "icl" and "cl"?). I think the best fix will be something like below:

#if _MSC_VER == 1900
			#include <../ucrt/float.h>
			#else
			#include __TMP_ANGLE_BRACKETS(__TMP_PASTE2(__MS_VC_INSTALL_PATH,/include/float.h))
			#endif

This will not break old MS versions and work for VS2015. I'll report this issue to our dev team to evaluate the best fix they prefer as they'll maintain for future versions (Hope this will not be changed again in VS 20xx !).

By the way, Tim seems like replied with another issue, which may not be related to this header. In fact, ucrt folder is already in INCLUDE in my environment.

Hope these helps.

Thanks,

Shenghong

TimP
Black Belt
447 Views

In my installation, ICL  INCLUDE path points to the original VS2015 install location C:\Program Files (x86)\Windows Kits\10\\include\10.0.10056.0\ucrt; although the VS2015 upgraded and moved the contents to 10069.0 while leaving a nearly empty copy of the original ucrt.  What little I can gather by web search indicates that vcvarsall.bat is responsible for this, but somehow my Windows Kits have been left at a much older version that what some others use.

Andre_N_
Beginner
447 Views

Hello

Thanks for your answer and for your suggestions. Yes, I think the header file needs to be changed for MSVC2015 to include the float.h from the right location. But the good thing is, that this was not the initial issue here :)

After compiling with "icl" everything is fine for me. I also tried again to compiler with "cl" and indeed I saw the message about the "third party tool". Now I know that this means ;-)
 

Anyway I think it was good to talk about this, since now everyone who gets the same error message will also find very fast the solution to take care to really use "icl" instead of "cl".

Thanks for your attention to this topic.
Best regards,
André

447 Views

@Tim,

Thank you for sharing the information. Yes, that should be an issue of vcvars.bat, Intel compiler does not handle this include path. Your information will be helpful for users getting this INCLUDE path issue (which may also indicate some error message like xxx.h NO such file or directory).

Thanks,

Shenghong

TimP
Black Belt
447 Views

I updated my VS2015 and it has become unusable, although the Windows Kits appears to have been straightened out.  So that wasn't a good move.   VS2013 seems nearly as good as 2015 was.