[Users] 'Ambiguous' g++ collisions on isnan (cmath), -std=gnu++0x

Ian Hinder ian.hinder at aei.mpg.de
Fri Aug 3 18:15:48 CDT 2012


On 4 Aug 2012, at 00:01, Ian Hinder wrote:

> 
> On 3 Aug 2012, at 19:01, Erik Schnetter wrote:
> 
>> isnan has been around since about 1977. The fact that std::isnan
>> doesn't work with the C++ Intel compiler is either a compiler bug, or
>> an installation problem. Of course, many people won't realise this
>> until they try to build Cactus, so we have to provide a work-around.
> 
> Hi Erik,
> 
> I'm trying to understand what is going on here.
> 
> According to http://en.cppreference.com/w/cpp/numeric/math/isnan, as well as several other pages I found on the internet, std::isnan is a new feature in C++11 (previously called C++0x).  By default, the Intel C++ compiler expects code conforming to C++98 (the original C++ standard) plus some GNU extensions.  If you use std::isnan, then your code should only be expected to work if compiled in C++11 mode.  For the Intel compiler, this requires the option
> 
> 	-std=c++0x
> 
> or 
> 
> 	-std=gnu++0x
> 
> if you also want GNU extensions.

Well, that was the theory, now on to the practice...

It seems that even in C++98 mode, the Intel compiler allows std::isnan.  The missing symbol errors are fixed by going from version 11.1.072 to 11.1.080 of the Intel compiler, indicating that it is, in fact, a bug/feature of that specific version of the compiler.

Even with the newer compiler, we still seem to need the -D__builtin_signbit=::signbit in CXXFLAGS for the signbit function.  Can you shed some light on what __builtin_signbit actually is?

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder



More information about the Users mailing list