Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Armando_L_A_
New Contributor I
371 Views

Where are Intel special math prototypes ?

Jump to solution

Dead friends.

Since I changed from Intel C++ Composer 2013  to 2017, the compiler is complaining of lack of prototypes for math functions that used to be in <mathimf.h>

For functions like sincos, sincosf, sind, cosd, etc , now I have to write the prototype to avoid warning.  But they are found by the linker. I always include <mathimf.h>

It is compiled under Windows 10, with VS 2015.  And compiled as C99 code (not C++). 

Thanks for any advice.

Armando

0 Kudos
1 Solution
Jingwei_Z_Intel
Employee
371 Views

Dear Armando,

I understand you do not include <math.h> yourself when Intel compiler is used. However, <process.h> on Windows include <math.h> itself, e.g., 

C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\ucrt\process.h includes <corecrt_startup.h>, which in turn includes <math.h>.

<math.h> is included by many Windows header files, so it's better to include <mathimf.h> first in your source code if you can.

Thanks,

Jingwei

 

View solution in original post

15 Replies
Melanie_B_Intel
Employee
371 Views

Those prototypes should be in mathimf. i tested a developer 17.0 and 18.0 compiler, not the product installation, but nevertheless I'd expect the same with the product. 

I did this experiment:

icl -c -E test.c > preproc.txt

Where test.c is #include <mathimf.h>

I can find a prototype declaration of sincos in the preprocessed output

Armando_L_A_
New Contributor I
371 Views

I know the prototypes are inside mathimf.h (have being using them from many years, since Intel C 7.xx).  If I create a small project it is OK. 

The problem is present on old big projects migrated from Intel C++ 2013.  Compiling with ICL 2013 it is OK; with 2017 I get the warnings.

I will to investigate more.

Thanks

jimdempseyatthecove
Black Belt
371 Views

>>The problem is present on old big projects

Have you experimented turning off IPO and/or multi-file IPO?

Jim Dempsey

Armando_L_A_
New Contributor I
371 Views

Dear Jim.

Thanks for the hint.  Unfortunately it did not work for me. It is a very odd situation, only triggered by Intel 2017 with MS VS 2015. On my other platform (Intel 2013, MS VC 2008) there is no problem for the same projects.

The warning is emitted at compile time.  I rewrote the include as:

#ifdef __INTEL_COMPILER
  #include  <mathimf.h>
  extern void  sincos(double __x, double *__psin, double *__pcos);
  extern void  sincosf(float __x, float  *__psin, float  *__pcos);
  extern double cosd(double x);
  extern double sind(double x);
#else
  #error  "not intel !"
  #include  <math.h>
#endif

 

The error is not showing, so the __INTEL_COMPILER is defined, but if the prototypes are removed the warning is generated.

For new simple projects, created under Intel 2017 with MS VC 2015, there are no problem.

By the way, I have (Intel 2017+MS VC) and (Intel 2013+MS VC 2008), both installed. Is this a source of conflicts ?

Armando

jimdempseyatthecove
Black Belt
371 Views

If I were venture a guess, this is an optimization issue. I suspect that the compiler optimization, after it attempts to resolve "vanilla flavored" sincos, cosd or sind, then substitutes the "vanilla flavored" library call with an Intel optimized call. It needs the prototype to get to the point of substitution. And this is why you get the warning for missing function prototype, yet linker resolves all symbols (including Intel re-directed functions).

You may be able to resolve this with:

#include <math.h>
#include <mathimf.h>

Although I haven't tried this.

Jim Dempsey

Armando_L_A_
New Contributor I
371 Views

Hi.  I found the source of the warning, but not the reason.

The order of my includes was:

#include  <fcntl.h>
#include  <sys\types.h>
#include  <sys\stat.h>
#include  <io.h>
#include  <stdlib.h>
#include  <stdio.h>
#include  <string.h>
#include  <time.h>
#include  <float.h>
#include  <ctype.h>
#include  <malloc.h>
#include  <stddef.h>
#include  <direct.h>
#include  <omp.h>
#include  <assert.h>
#include  <process.h>


#ifdef __INTEL_COMPILER
    #include  <mathimf.h>
#else
    #include  <math.h>
#endif

With the previous order, the warning was triggered. 

If <process.h> is moved after <mathimf.h> inclusion, the problem is gone !!  Now it is:

#include  <fcntl.h>
#include  <sys\types.h>
#include  <sys\stat.h>
#include  <io.h>
#include  <stdlib.h>
#include  <stdio.h>
#include  <string.h>
#include  <time.h>
#include  <float.h>
#include  <ctype.h>
#include  <malloc.h>
#include  <stddef.h>
#include  <direct.h>
#include  <omp.h>
#include  <assert.h>

#ifdef __INTEL_COMPILER
    #include  <mathimf.h>
#else
    #include  <math.h>
#endif

#include  <process.h>

<process.h>   should no be before  <mathimf.h>

Any ideas ? 

Thanks

Armando

 

 

 

 

 

 

 

 

jimdempseyatthecove
Black Belt
371 Views

I cannot imagine that process is using sincos, cosd, or sind, however process.h or mathimf.h may have conflicting #define and/or #if expansions.

Glad you found a solution. I have been experiencing similar issues here, though not with mathimf (don't use it).

Jim Dempsey

Armando_L_A_
New Contributor I
371 Views

Dear Jim,

Sorry, it took me some time to check with other projects. Now I can confirm, if specials functions from <mathimf.h> are used and the include is preceded by <process.h>,  the prototypes are not included as expected.

On the other hand, I found no <process.h> on the installation directories of INTEL C, so it should be using the file from Microsft Visual C++. This can be the source of conflict.

I checked for Intel C 2017, update 4, under MS VC 2015.  Intel C 2013 under MS VC 2008 had no problem.

If I were in position to classify the issue, I would say it is a bug on the compiler.

Regards,

Armando

 

jimdempseyatthecove
Black Belt
371 Views

FWIW see: https://stackoverflow.com/questions/24328173/c-libstd-compute-sin-and-cos-simultaneously

sincos is not part of C++ standards, however it is available in GNU C and C99

In looking at mathimf.h:

#if defined(__APPLE__) || (!defined(__QNX__) && !defined(__VXWORKS__) && !(defined(__unix__) && defined(__USE_ISOC99)))
_LIBIMF_EXT _LIBIMF_VOID     _LIBIMF_PUBAPI sincos( _LIBIMF_DOUBLE __x, _LIBIMF_DOUBLE *__psin, _LIBIMF_DOUBLE *__pcos );
_LIBIMF_EXT _LIBIMF_VOID     _LIBIMF_PUBAPI sincosf( _LIBIMF_FLOAT __x, _LIBIMF_FLOAT *__psin, _LIBIMF_FLOAT *__pcos );
_LIBIMF_EXT _LIBIMF_VOID     _LIBIMF_PUBAPI sincosl( _LIBIMF_XDOUBLE __x, _LIBIMF_XDOUBLE *__psin, _LIBIMF_XDOUBLE *__pcos );
#endif /* __USE_ISOC99 */

You should get sincos if you qualify the #if expression. On Windows, you would have to enable C99.

Jim Dempsey

Armando_L_A_
New Contributor I
371 Views

Dear Jim.  Thanks for the clarification.  I am forced to use C99  ( /Qstd=c99 ), due to extensive use of Variable Length Arrays (VLA), inline , restrict, stdint.h, etc

So the problem is not related to lack of C99 standard, it is some obscure side effect of including process.h  before mathimf.h . And this is a new problem, because I have used Intel compiler for years without that issue.

As we now know the solution, the problem is no bothering us any more, but I guess it is advisable to the compiler team to look at some conflict on the Intel.2017 - Visual Studio 2015 integration.

Regards,

Armando

Melanie_B_Intel
Employee
371 Views

Armando, Thanks for the detailed investigation about how to reproduce the problem. I opened cmplrs-46301 in our internal bugs database to track the problem.  There is a white paper that discusses using both system math.h and mathimf.h in the same file, see https://software.intel.com/en-us/articles/mathimfh-is-incompatible-with-system-mathh

Armando_L_A_
New Contributor I
371 Views

Dear Melaine, Thanks for for your interest in our problem.

Only one detail that might not be clear for our case: I never use <math.h>  mixed with <mathimf.h>  For our Windows/PC products we use exclusively INTEL C++ (C99). For any source that could be used outside Intel Compiler we write:

#ifdef __INTEL_COMPILER
    #include  <mathimf.h>
#else
    #include  <math.h>
#endif

Best regards,

Armando

 

 

 

Melanie_B_Intel
Employee
371 Views

Thank you.  I will add that note into the bug report.

Jingwei_Z_Intel
Employee
372 Views

Dear Armando,

I understand you do not include <math.h> yourself when Intel compiler is used. However, <process.h> on Windows include <math.h> itself, e.g., 

C:\Program Files (x86)\Windows Kits\10\Include\10.0.15063.0\ucrt\process.h includes <corecrt_startup.h>, which in turn includes <math.h>.

<math.h> is included by many Windows header files, so it's better to include <mathimf.h> first in your source code if you can.

Thanks,

Jingwei

 

View solution in original post

Armando_L_A_
New Contributor I
371 Views

Dear Jingwei.

Thanks for your feedback. It is a good advice for all <mathimf.h> users and it is the first time I find a clear answer this issue.

Best Regards,

Armando

 

Reply