[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