Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

Where are Intel special math prototypes ?

Armando_L_A_
New Contributor I
1,055 Views

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
1,055 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

0 Kudos
15 Replies
Melanie_B_Intel
Employee
1,055 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

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,055 Views

>>The problem is present on old big projects

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

Jim Dempsey

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,055 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

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

 

 

 

 

 

 

 

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,055 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

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

 

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,055 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

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

0 Kudos
Melanie_B_Intel
Employee
1,055 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

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

 

 

 

0 Kudos
Melanie_B_Intel
Employee
1,055 Views

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

0 Kudos
Jingwei_Z_Intel
Employee
1,056 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

 

0 Kudos
Armando_L_A_
New Contributor I
1,055 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

 

0 Kudos
Reply