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

[Erik Schnetter]

The signbit function returns and integer 1 or 0 for negative or
positive values, respectively (the sign bit). "Builtin" functions are
usually a compiler mechanism -- the compiler knows how to implement
certain functions (e.g. add, subtract, multiply, absolute value,
etc.), and instead of emitting a function call, produces directly the
code implementing these functions. In many cases, builtin functions
translated to a single machine instruction, plus surrounding fluff to
move stuff from memory to registers.

As such, builtin functions do not really exist. They are declared, but
their implementation is built into the compiler. The fact that the
compiler creates a call to a builtin function means that something is
seriously wrong. I assume that, on this system, gcc knows this builtin
function, and math.h uses a macro to map signbit to __builtin_signbit
(maybe depending on the type of the argument, there is probably also a
__builtin_signbitf), expecting the compiler to know this builtin.
Unfortunately, the Intel compiler doesn't seem to know about this
function, and generates a function call.

If this is so, the "correct" solution is to use a gcc version / Linux
version that is officially supported by the Intel compiler, probably a
version that is a few months or years older than the one present. Of
course, we don't want to do this, so we google for work-arounds, and
this would be -D__builtin_signbit=std::signbit.

We should probably autoconf this; this problem has been around for
quite some time and doesn't seem to be going away.

-erik

On Fri, Aug 3, 2012 at 7:15 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> 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
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/