http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot
com> 2012-08-01 15:41:01 UTC ---
On Wed, 1 Aug 2012, glisse at gcc dot gnu.org wrote:
> may also break stuff if the C library uses isnan. I could also ask glibc to
> not
> declare the isnan function at all in C++, but that's a bit strange and other C
> libraries may define an isnan function.
The isnan function declaration is for compatibility with some old
standards such as Unix98 that had such a function instead of the
type-generic macro. It would seem reasonable to disable it for C++, just
as the glibc headers allow for C++ requirements for overloads in string.h,
for example. It is, however, really for the libstdc++ maintainers to work
with the glibc maintainers regarding any changes to C headers that would
be helpful for meeting C++ standard requirements; we can't make such a
change in isolation without knowing it fits in with the libstdc++
maintainer plans.
> Note also that in C, we are currently failing to optimize this to a constant:
> #include <math.h>
> int f(){return isnan(3);}
The isnan macro definition is an old one, maybe predating GCC's
type-generic __builtin_isnan, that calls functions such as __isnan, so
effectively preventing such constant folding. It would seem reasonable,
given recent enough GCC versions, for it to use the type-generic built-in
function instead, and likewise for various other such macros in glibc
(maybe not fpclassify because of code size, and for isinf you have the
complication of glibc providing additional semantics beyond the standard
version). If making such a change, it would seem appropriate also to
change the internal calls to functions such as __isnan to call the macros
instead, letting the compiler generate the most appropriate code.
