Re: [patch] libstdc++/48891 Use ::isinf and ::isnan if libc defines them

[Jonathan Wakely <jwakely at redhat dot com>]

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?