[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #12 from Jiang An --- (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).
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 Jonathan Wakely changed: What|Removed |Added CC||vincenzo.innocente at cern dot ch --- Comment #11 from Jonathan Wakely --- *** Bug 114484 has been marked as a duplicate of this bug. ***
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #10 from Jonathan Wakely --- Ville brought a related case to my attention. With Glibc this compiles, and finds libc's ::sqrt(double) #include 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 , only by , 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 Jonathan Wakely changed: What|Removed |Added CC||oscar.smith@juliacomputing. ||com --- Comment #9 from Jonathan Wakely --- *** Bug 103304 has been marked as a duplicate of this bug. ***
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #8 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #7 from James Y Knight --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #6 from James Y Knight --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #5 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #4) > DR 456: PR6257 That's what established the status quo, which James referred to as "While may or may not declare functions in ::std::, and may or may not declare functions in ::". We meet that requirement, but that's not the problem described here. The problem is that the new rules established by DR 456 are not sufficient to produce consistent overload sets.
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #4 from Andrew Pinski --- DR 456: PR6257
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-27 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Libc++ avoids the problem by adding the additional overloads to the global namespace in the C++ versions of and , then having the headers include the headers. We do it the other way around, so that the original libc function is in the global namespace, and the additional overloads are in namespace std, and that difference is the root cause.
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #2 from Jonathan Wakely --- The same problem exists for ::div in , and for ::abs in both and . Calling ::abs(INT_MAX + 1LL) or abs(INT_MAX + 1LL) will overflow and so is undefined. Clang warns about this and suggests using std::abs instead: abs.cc:5:10: warning: absolute value function 'abs' given an argument of type 'long' but has parameter of type 'int' which may cause truncation of value [-Wabsolute-value] return ::abs(long(argc) << 32); ^ abs.cc:5:10: note: use function 'std::abs' instead return ::abs(long(argc) << 32); ^ std::abs It doesn't warn for the log(f) example above though. (In reply to Andrew Pinski from comment #1) > I there is a related defect report against the c++ standard about this exact > issue. I don't think there is. Only regarding abs, which used to be defined differently in two different headers. That was changed by: https://cplusplus.github.io/LWG/issue2294 and https://cplusplus.github.io/LWG/issue2192 (And it had previously been touched on by https://cplusplus.github.io/LWG/issue323 which was closed as NAD). I don't recall an issue about the more general problem of functions other than abs.
[Bug libstdc++/89855] Inconsistent global namespace overload sets from #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89855 --- Comment #1 from Andrew Pinski --- I there is a related defect report against the c++ standard about this exact issue.
