Where are Intel special math prototypes ?

[Armando_L_A_]

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

[Melanie_B_Intel]

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_]

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]

>>The problem is present on old big projects

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

Jim Dempsey

[Armando_L_A_]

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]

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_]

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]

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_]

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]

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_]

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]

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_]

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]

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

[Jingwei_Z_Intel · Accepted solution]

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

[Armando_L_A_]

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