- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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().
- Tags:
- CC++
- Development Tools
- Intel® C++ Compiler
- Intel® Parallel Studio XE
- Intel® System Studio
- Optimization
- Parallel Computing
- Vectorization
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the same issue
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Judith,
There are many issues with 1028 Update 1 release.
Please check other forum posts.
Thank You.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compatibility issue will be fixed in our next release.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page