[patch] libstdc++/48891 Use ::isinf and ::isnan if libc defines them
Jonathan Wakely
jwakely@redhat.com
Wed Jan 13 16:26:00 GMT 2016
On 08/01/16 13:59 +0000, Jonathan Wakely wrote:
>Glibc defines obsolete isinf(double) and isnan(double) functions from
>Unix98. For C99 these are hidden by the type-generic isinf and isnan
>macros, but in C++11 <cmath> #undefs those macros, exposing the Unix98
>functions. They then conflict with our own std::isinf(double) and
>std::isnan(double) if users add them to the global namespace:
>
>#include <cmath>
>using std::isinf;
>
>d.cc:3:12: error: âconstexpr bool std::isinf(double)â conflicts with a previous declaration
>using std::isinf;
> ^
>
>This has been reported three times now, and with the fix I'm planning
>for PR14608 this becomes essential to fix, because I'm adding a
><math.h> wrapper containing exactly the code above.
>
>At https://sourceware.org/bugzilla/show_bug.cgi?id=19439 I've proposed
>a glibc patch to suppress those functions for C++11 and later, but we
>still need to make libstdc++ work with existing glibc releases.
>
>This patch adds a configure check for non-macro isinf and isnan
>declarations, and pulls them into namespace std when they're found.
>This means we define the functions with the wrong return type (int not
>bool) but that's better than having conflicting declarations that
>don't compile at all!
>
>I'm only checking for those functions for *-*-*gnu* targets, as I
>don't know of any other targets where it's an issue. Solaris and
>the BSDs don't define those functions. If it affects other targets we
>can extend the check to cover them too.
>
>With a fixed glibc (or other C libraries that don't declare those
>functions) we continue to define extern "C++" bool std::isinf(double),
>which is the correct signature and mangles differently to the glibc
>functions.
>
>I've tested this on x86_64-linux with and without the glibc fix, and
>on powerpc64-linux and x86_64-freebsd10.2 and although the interaction
>between libc and libstdc++ is always tricky, I'm confident it's safe
>and certainly more correct than what we have now. We could potentially
>even backport it to the branches.
>
>Does anyone see any problem with this patch, or the proposed glibc
>change?
>
>commit e5a8514077918b7885266ab3e136ae7b8ad65f99
>Author: Jonathan Wakely <jwakely@redhat.com>
>Date: Thu Jan 7 16:01:09 2016 +0000
>
> Use ::isinf and ::isnan if libc defines them
>
> PR libstdc++/48891
> * acinclude.m4 (GLIBCXX_CHECK_MATH11_PROTO): Check for obsolete isinf
> and isnan functions.
> * config.h.in: Regenerate.
> * configure: Regenerate.
> * include/c_global/cmath (isinf(double), isnan(double))
> [_GLIBCXX_HAVE_OBSOLETE_ISINF_ISNAN]: Import via using-directive.
> * testsuite/26_numerics/headers/cmath/48891.cc: New.
Committed to trunk.
My patch to suppress those functions for >= C++11 has also been
committed to glibc.
Should we backport the libstdc++ fix to the branches too?
More information about the Libstdc++
mailing list