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

Scott Hawley scott.hawley at belmont.edu
Fri Aug 3 12:48:23 CDT 2012 

Here's a sneaky suggestion:  in the pre-processor script used on C++
files, replace instances "cmath.h" with "cmath".  It seems to be these two
files which end up in conflict, and only one is needed.



On 8/3/12 12:01 PM, "Erik Schnetter" <schnetter at cct.lsu.edu> 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.
>
>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?
>
>-erik
>
>On Fri, Aug 3, 2012 at 12:08 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>>
>> On 3 Aug 2012, at 13:45, Erik Schnetter wrote:
>>
>>> I don't know why the __builtin_isnan etc. are not defined for some
>>> versions of the Intel compilers. I suspect an incompatibility with the
>>> Intel compiler and the respective system libraries (which provide
>>> math.h). I have updated the Simfactory option lists.
>>
>> The tests pass again
>>(http://damiana2.aei.mpg.de/~ianhin/testreports/EinsteinToolkitTests/resu
>>lts.xml); thanks!
>>
>> Is there a more general way of solving this problem, rather than
>>solving it in each machine's option list?  I'm worried that we have a
>>lot of special-case options in our option lists now, and that new users
>>will be essentially unable to use Cactus unless they have an expert to
>>write an optionlist for them.  We have many exceptions and special flags
>>in the optionlists now, each added to solve a specific problem.  I think
>>these should be solved in a more general way.  For example, if isnan is
>>not sufficiently portable that it can be used on any compiler, can we
>>provide an autoconf test for it and a Cactus isnan function which calls
>>the right thing?  This goes for all the other options which we have.
>>For example, for Datura, one currently has:
>>
>> CPPFLAGS =
>> FPPFLAGS = -traditional
>> CFLAGS   = -g -debug all -traceback -align -std=c99 -ansi_alias
>>-U__STRICT_ANSI__ -rdynamic
>> CXXFLAGS = -g -debug all -traceback -align -restrict -rdynamic
>>-D__builtin_isnan=::isnan -D__builtin_signbit=::signbit
>> F77FLAGS = -g -debug all -traceback -align -pad -w95 -cm
>> F90FLAGS = -g -debug all -traceback -align -pad -w95 -cm
>>
>> I understand that adding these to the option list is the safest thing
>>to do and provides a conservative quick fix, but at some point,
>>shouldn't these things move into Cactus?
>>
>>
>>>
>>> -erik
>>>
>>> On Fri, Aug 3, 2012 at 3:44 AM, Ian Hinder <ian.hinder at aei.mpg.de>
>>>wrote:
>>>>
>>>> On 2 Aug 2012, at 22:40, Erik Schnetter wrote:
>>>>
>>>>> Try now.
>>>>
>>>> This causes a build failure on Datura:
>>>>
>>>>        
>>>>http://git.barrywardell.net/EinsteinToolkitTestResults.git/blob/c32794e
>>>>5e57db36da2fede2f1eec451daf108a9c:/build.log
>>>>
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/configs/EinsteinToolkitTests_
>>>>>bb930fc2b4a2900b3c5a780e79244bb0ddefb81d/lib/libthorn_Vectors.a(test.c
>>>>>c.o): In function `Vectors_Test':
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/arrangements/LSUThorns/Vector
>>>>>s/src/test.cc:252: undefined reference to `__builtin_isnan'
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/arrangements/LSUThorns/Vector
>>>>>s/src/test.cc:252: undefined reference to `__builtin_isnan'
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/arrangements/LSUThorns/Vector
>>>>>s/src/test.cc:251: undefined reference to `__builtin_isnan'
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/arrangements/LSUThorns/Vector
>>>>>s/src/test.cc:251: undefined reference to `__builtin_isnan'
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/arrangements/LSUThorns/Vector
>>>>>s/src/test.cc:249: undefined reference to `__builtin_isnan'
>>>>> 
>>>>>/home/ianhin/Cactus/EinsteinToolkitTests/configs/EinsteinToolkitTests_
>>>>>bb930fc2b4a2900b3c5a780e79244bb0ddefb81d/lib/libthorn_Vectors.a(test.c
>>>>>c.o):/home/ianhin/Cactus/EinsteinToolkitTests/arrangements/LSUThorns/V
>>>>>ectors/src/test.cc:249: more undefined references to
>>>>>`__builtin_isnan' follow
>>>>> make[1]: *** 
>>>>>[/home/ianhin/Cactus/EinsteinToolkitTests/exe/cactus_EinsteinToolkitTe
>>>>>sts_bb930fc2b4a2900b3c5a780e79244bb0ddefb81d] Error 1
>>>>> make: *** 
>>>>>[EinsteinToolkitTests_bb930fc2b4a2900b3c5a780e79244bb0ddefb81d] Error
>>>>>2
>>>>> 0.10user 0.27system 12:11.56elapsed 0%CPU (0avgtext+0avgdata
>>>>>14928maxresident)k
>>>>> 0inputs+3032outputs (0major+1354minor)pagefaults 0swaps
>>>>> Build failed
>>>>
>>>>>
>>>>> -erik
>>>>>
>>>>> On 2012-08-02, at 15:36 , Erik Schnetter <schnetter at cct.lsu.edu>
>>>>>wrote:
>>>>>
>>>>>> The solution is likely to wrap the calls to isnan into a my_isnan
>>>>>>function, similar to the way in which signbit is wrapped. I am
>>>>>>testing a patch.
>>>>>>
>>>>>> -erik
>>>>>>
>>>>>> On 2012-08-02, at 15:14 , Scott Hawley <scott.hawley at belmont.edu>
>>>>>>wrote:
>>>>>>
>>>>>>> I added '-D__builtin_isinf=::isinf -D__builtin_isnan=::isnan' as I
>>>>>>>saw in
>>>>>>> a few simfactory .cfg files, but no luck.
>>>>>>>
>>>>>>> (Thanks to
>>>>>>> 
>>>>>>>http://lists.einsteintoolkit.org/pipermail/users/2011-June/001151.ht
>>>>>>>ml)
>>>>>>>
>>>>>>> There is currently no nautilus.cfg file, but if someone would like
>>>>>>>access
>>>>>>> to Nautilus in order to make one (which is what I seem to be doing,
>>>>>>> slowly), I'd be happy to add you to my allocation! :-)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/2/12 1:58 PM, "Scott Hawley" <scott.hawley at belmont.edu> wrote:
>>>>>>>
>>>>>>>> Hi.  The following is a well-documented collision that occurs
>>>>>>>>with the
>>>>>>>> cmath header.
>>>>>>>>
>>>>>>>> The fixes I've seen around the 'net all involve modifying the
>>>>>>>>source and
>>>>>>>> putting in #define statements. But the code in question isn't
>>>>>>>>mine.
>>>>>>>>
>>>>>>>> Is there a "-f_____" compiler flag I set instead?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Scott
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> COMPILING
>>>>>>>> 
>>>>>>>>/nics/c/home/hawleys/Cactus/arrangements/LSUThorns/Vectors/src/test
>>>>>>>>.cc
>>>>>>>> current_wd=`pwd` ; cd
>>>>>>>>/nics/c/home/hawleys/Cactus/configs/texmex/scratch ;
>>>>>>>> g++ -LMPICH_IGNORE_CXX_SEEK -g -DCARPET_DEBUG  -fopenmp  -O2 -m64
>>>>>>>> -std=gnu++0x -g -O0 -O3 -fopenmp  -c -o $current_wd/test.cc.o
>>>>>>>> $current_wd/test.cc
>>>>>>>> -I"/nics/c/home/hawleys/Cactus/arrangements/LSUThorns/Vectors/src"
>>>>>>>> 
>>>>>>>>-I"/nics/c/home/hawleys/Cactus/arrangements/LSUThorns/Vectors/src/i
>>>>>>>>nclude"
>>>>>>>> -I"/nics/c/home/hawleys/Cactus/configs/texmex/config-data"
>>>>>>>> -I"/nics/c/home/hawleys/Cactus/configs/texmex/bindings/include"
>>>>>>>> -I"/nics/c/home/hawleys/Cactus/src/include"
>>>>>>>> -I"/nics/c/home/hawleys/Cactus/arrangements"
>>>>>>>> 
>>>>>>>>-I"/nics/c/home/hawleys/Cactus/configs/texmex/bindings/Configuratio
>>>>>>>>n/Thorn
>>>>>>>> s
>>>>>>>> " 
>>>>>>>>-I"/nics/c/home/hawleys/Cactus/configs/texmex/bindings/include/Vect
>>>>>>>>ors"
>>>>>>>> -I"/nics/c/home/hawleys/Cactus/arrangements/LSUThorns/Vectors/src"
>>>>>>>> 
>>>>>>>>-I"/nics/c/home/hawleys/Cactus/arrangements/LSUThorns/Vectors/src/i
>>>>>>>>nclude"
>>>>>>>> 
>>>>>>>>-I"/nics/c/home/hawleys/Cactus/configs/texmex/bindings/include/Vect
>>>>>>>>ors"
>>>>>>>> -DCCODE
>>>>>>>> /nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors/test.cc:
>>>>>>>>In
>>>>>>>> function Œvoid Vectors_Test(cGH*)¹:
>>>>>>>> 
>>>>>>>>/nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors/test.cc:11
>>>>>>>>2:3:
>>>>>>>> error: call of overloaded Œisnan(double&)¹ is ambiguous
>>>>>>>> 
>>>>>>>>/nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors/test.cc:11
>>>>>>>>2:3:
>>>>>>>> note: candidates are:
>>>>>>>> /usr/include/bits/mathcalls.h:235:1: note: int isnan(double)
>>>>>>>> 
>>>>>>>>/nics/e/sw/local/nautilus/opt/gcc/4.6.3/bin/../lib/gcc/x86_64-unkno
>>>>>>>>wn-linu
>>>>>>>> x
>>>>>>>> -gnu/4.6.3/../../../../include/c++/4.6.3/cmath:552:3: note: bool
>>>>>>>> std::isnan(long double)
>>>>>>>> 
>>>>>>>>/nics/e/sw/local/nautilus/opt/gcc/4.6.3/bin/../lib/gcc/x86_64-unkno
>>>>>>>>wn-linu
>>>>>>>> x
>>>>>>>> -gnu/4.6.3/../../../../include/c++/4.6.3/cmath:548:3: note: bool
>>>>>>>> std::isnan(double)
>>>>>>>> 
>>>>>>>>/nics/e/sw/local/nautilus/opt/gcc/4.6.3/bin/../lib/gcc/x86_64-unkno
>>>>>>>>wn-linu
>>>>>>>> x
>>>>>>>> -gnu/4.6.3/../../../../include/c++/4.6.3/cmath:544:3: note: bool
>>>>>>>> std::isnan(float)
>>>>>>>> 
>>>>>>>>/nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors/test.cc:11
>>>>>>>>2:3:
>>>>>>>> error: call of overloaded Œisnan(double&)¹ is ambiguous
>>>>>>>> 
>>>>>>>>/nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors/test.cc:11
>>>>>>>>2:3:
>>>>>>>> note: candidates are:
>>>>>>>> /usr/include/bits/mathcalls.h:235:1: note: int isnan(double)
>>>>>>>> (  ...more of the same...   )
>>>>>>>> make[3]: *** [test.cc.o] Error 1
>>>>>>>> make[3]: Leaving directory
>>>>>>>> `/nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors'
>>>>>>>> make[2]: *** [make.checked] Error 2
>>>>>>>> make[2]: Leaving directory
>>>>>>>> `/nics/c/home/hawleys/Cactus/configs/texmex/build/Vectors'
>>>>>>>> make[1]: ***
>>>>>>>> 
>>>>>>>>[/nics/c/home/hawleys/Cactus/configs/texmex/lib/libthorn_Vectors.a]
>>>>>>>> Error
>>>>>>>> 2
>>>>>>>> make[1]: Leaving directory `/nics/c/home/hawleys/Cactus'
>>>>>>>> make: *** [texmex] Error 2
>>>>>>>>
>>>>>>>> hawleys/Cactus> g++ --version
>>>>>>>> g++ (GCC) 4.6.3
>>>>>>>> Copyright (C) 2011 Free Software Foundation, Inc.
>>>>>>>> This is free software; see the source for copying conditions.
>>>>>>>>There is NO
>>>>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>>>>>>> PURPOSE.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at einsteintoolkit.org
>>>>>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at einsteintoolkit.org
>>>>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>>>>
>>>>>> --
>>>>>> Erik Schnetter <eschnetter at perimeterinstitute.ca>
>>>>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>>>>> AIM: eschnett247, Skype: eschnett, Google Talk: schnetter at gmail.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at einsteintoolkit.org
>>>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>>>
>>>>> --
>>>>> Erik Schnetter <eschnetter at perimeterinstitute.ca>
>>>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>>>> AIM: eschnett247, Skype: eschnett, Google Talk: schnetter at gmail.com
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at einsteintoolkit.org
>>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>>
>>>> --
>>>> Ian Hinder
>>>> http://numrel.aei.mpg.de/people/hinder
>>>>
>>>
>>>
>>>
>>> --
>>> Erik Schnetter <schnetter at cct.lsu.edu>
>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>
>> --
>> Ian Hinder
>> http://numrel.aei.mpg.de/people/hinder
>>
>
>
>
>-- 
>Erik Schnetter <schnetter at cct.lsu.edu>
>http://www.perimeterinstitute.ca/personal/eschnetter/
>

More information about the Users mailing list