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

[Ian Hinder]

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.

Looking through the option lists in simfactory, some use C++11 and some use C++98 (by omitting the -std option, and leaving it to the compiler default, which is gnu++0x) .  Since the choice of language standard is common to all thorns in a configuration, I think we should define which language standard can be expected within the ET (and possibly globally for Cactus).  

Can we expect all supported compilers to work with C++11 on all the different architectures? If so, then we should state that the code in the ET should be compiled in C++11 mode, possibly extending this to Cactus, and having the -std=gnu++0x option added automatically.  If not, then we should avoid using C++11 features in the ET, unless we implement them ourselves.  We can then ask if we also support compiling in C++11 mode.  The same question then needs to be asked about the different C language standards, but I have a feeling that the situation there is more hairy.

> The problem is that things probably depend on whether math.h or cmath
> have been included, and in which order they have been included. C
> requires isnan to be a macro, whereas C++ requires it to be a
> function. Our current solution allows isnan to be inlined, which is
> probably not so important for isnan, but may be important for signbit
> or copysign. I wonder how a portable implementation of an (inlineable)
> cctk_copysign would look like. It would mean that we stick the
> work-arounds for compiler bugs and "misunderstanding" about the C++
> standard into this function's implementation instead of option lists.
> 
> I think this is a good idea. cctk_math.h?

If possible, I would prefer that users can write standards-conforming "normal" code.  If there are compiler bugs that we need to work around, maybe we can detect these using autoconf and redefine functions etc so that they behave in a standards-conforming way.  This means that when the bugs are fixed, we can drop the workarounds, and users' code won't need to be changed.  In this case though, I'm not convinced that it is a compiler bug.  

Regarding the change to Vectors, the problem seems to be that both cmath and math.h are being included, and they both offer versions of the isnan function.  Why is it necessary to wrap the call with another function?  Could you not just replace occurrences of isnan with std::isnan? Or does the wrapping also disambiguate the types?

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