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

icpc 18.0.1 for Mac breaks cmath

John_G_8
Beginner
918 Views

I just upgraded to Intel C++ version 18.0.1 and discovered that cmath is apparently broken. The simple program

#include <cmath>
int main(int argc,char **argv)
{
    double x = 0.0/0.0;
    if (std::isnan(x)) return 0;
    else return 1;

}

will not compile (it would for previous versions of Intel and works fine for GNU). The error message I get is

icpc isnan.cc

isnan.cc(5): error: expected an identifier
      if (std::isnan(x)) return 0;

I get the same error for other floating point checks like std::isfinite().

 

0 Kudos
7 Replies
MGRAV
New Contributor I
918 Views

I have the same issue

0 Kudos
John_G_8
Beginner
918 Views

As I figured, this problem is due to the fact that the Intel compilers (all versions) are still not compatible with Xcode 9. I thought this would be fixed in the new version, but I thought wrong. Downgrading to Xcode 8.3.3 works around this problem for the Intel compilers, but breaks other things I need like being able to compile iTerm2 which requires Xcode 9. I reported this problem when I upgraded to Xcode 9 several weeks ago and was told to wait for the next release and that the Intel developers were aware of this issue. The problem here seems to be that icpc does not specify itself to Xcode 9 in a way that recognizes that these standard templates exist. Instead it appears that the isnan (and other members) expressions get expanded as macros and the expression std::isnan(x) becomes a garbled to the compiler.

0 Kudos
Judith_W_Intel
Employee
918 Views

 

This is entered as cmplrs-46023 in our bug database (still open).

Below is the analysis of the problem. I think adding the #undef isinf  right after the <cmath> header is included would workaround the problem.

Judy

So it looks like this is a problem with the interaction of the Intel substitute header <math.h> and the new Xcode <cmath> and <math.h> headers.

Previous versions of the <cmath> header on Xcode used to do an #undef of isinf, i.e.:

sptem24-1011> grep undef cmath*mac | grep isinf  Xcode 9 version
sptem24-1012> grep undef /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath | grep isinf  OLDER VERSION
#undef isinf

The new version of Xcode does an #undef of isinf in <math.h> (NOT cmath) after it has been defined and if it’s cplusplus mode:

From /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/math.h:

sptem24-1015> grep -n undef math*frommac | grep isinf
426:#undef isinf

In other words Xcode 9 moved some stuff from <cmath> to <math.h>.

But our substitute <math.h> header is similar to the pre-Xcode 9 version of <math.h> and is no longer compatible.

0 Kudos
MGRAV
New Contributor I
918 Views

Hi,

 

​I find this solution too of adding #undef insan #undef isinf where is needed just after the #include <cmath>.

However, if I understood well the problem is that the Intel math.h and Xcode math.h are not compatible, no ?

Is it not possible to use the Xcode math.h until the problem is solved ?

0 Kudos
Royi
Novice
918 Views

@Judith,

There are many issues with 1028 Update 1 release.
Please check other forum posts.

Thank You.

0 Kudos
Judith_W_Intel
Employee
918 Views

 

Just a clarification - this is not caused by something new in 18.0 Update 1. The change that's causing the problem is in the new Xcode headers. I haven't tried it but perhaps including the Xcode version of math.h instead of the Intel version (presumably by specifying the complete path in the #include?) would workaround the problem too.

Judy

0 Kudos
Jingwei_Z_Intel
Employee
918 Views

The compatibility issue will be fixed in our next release. 

0 Kudos
Reply