[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[foom at fuhm dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

--- Comment #6 from James Y Knight <foom at fuhm dot net> ---
Someone has pointed out to me that the standard actually says "name", which I
had internalized as meaning "declaration", but it doesn't. This arguably does
make the GCC implementation non-compliant with the spec.


>From http://eel.is/c++draft/headers#5

> Except as noted in [library] through [thread] and [depr], the contents of each header cname is the same as that of the corresponding header name.h as specified in the C standard library. In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope of the namespace std. It is unspecified whether these names (including any overloads added in [support] through [thread] and [depr]) are first declared within the global namespace scope and are then injected into namespace std by explicit using-declarations.

I think that text implies that all of the overloads of a particular name must
consistently either be defined in the global namespace (and then imported into
std with a using-declaration) or defined in the std namespace.

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[foom at fuhm dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

--- Comment #7 from James Y Knight <foom at fuhm dot net> ---
Ugh, GCC doesn't wrap quoted text? Re-posting the quote from
http://eel.is/c++draft/headers#5 without a quote marker...

"""
Except as noted in [library] through [thread] and [depr], the contents of each
header cname is the same as that of the corresponding header name.h as
specified in the C standard library. In the C++ standard library, however, the
declarations (except for names which are defined as macros in C) are within
namespace scope of the namespace std. It is unspecified whether these names
(including any overloads added in [support] through [thread] and [depr]) are
first declared within the global namespace scope and are then injected into
namespace std by explicit using-declarations.
"""

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That's one possible reading, but I don't think the text you quote is precise
enough to say that reading is definitely correct or not. If that is what it
says, it might be unintentional. That paragraph is hardly a paragon of
precision. The current wording was added by https://wg21.link/lwg456 to address
the problem that the original wording didn't reflect reality and was
effectively unimplementable for some vendors. I see nothing in 456 that implies
your reading was intended (and nothing impying it wasn't).

It doesn't really make any difference anyway, since I already plan to change
libstdc++ to resolve the original problem described above.

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oscar.smith@juliacomputing.
                   |                            |com

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 103304 has been marked as a duplicate of this bug. ***

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ville brought a related case to my attention. With Glibc this compiles, and
finds libc's ::sqrt(double)

#include <cmath>
int i = sqrt(0);

But on Solaris it doesn't even compile. Solaris libc provides all three of
sqrt(float), sqrt(double), sqrt(long double), which makes this ambiguous.

The additional overload that works for integral types is not provided by
Solaris libc's <math_iso.h>, only by <cmath>, and so can't be found here
because there is no 'using std::sqrt;' to put it into the global namespace.

So this compiles and even gives the expected result (returning a double) on
linux, but fails to compile on Solaris.

This suggests that we even need the additional overloads for integral arguments
to be unconditionally dumped into both the global namespace and std.

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincenzo.innocente at cern dot ch

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 114484 has been marked as a duplicate of this bug. ***

[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include <cmath>

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #12 from Jiang An <de34 at live dot cn> ---
(In reply to Andrew Pinski from comment #1)
> I there is a related defect report against the c++ standard about this exact
> issue.

I think this is LWG 2380 (https://cplusplus.github.io/LWG/issue2380).