<div dir="ltr">Hi Martin,<div><br></div><div>If you disagree you'll need to cite (or change) the standard. IMO the standard is explicitly clear on this topic. <br><div><br></div><div>15.2 [library.c] says:</div><div>> The C ++ standard library also makes available the facilities of the C standard library, suitably adjusted to<div>> ensure static type safety.<br></div><div><br></div><div>D.3 [depr.c.headers] says:</div><div>>1. every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard</div><div>> library namespace by the corresponding cname header is placed within the global namespace scope. It is<br></div><div>> unspecified whether these names are first declared or defined within namespace scope (3.3.6) of the namespace<br></div><div>> std and are then injected into the global namespace scope by explicit using-declarations (7.3.3).<br></div><div><br></div><div>/Eric</div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 23, 2016 at 12:50 PM, Martin J. O'Riordan via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I disagree. I'm not new to C++ either, I built my first C++ compiler in 1986 and have been involved in C++ standardisation for a very long time, and the recent changes are wrong.<br>
<br>
Including "math.h" should NOT introduce overloaded versions of 'fabs' or other functions at global scope. It may only introduce the overloaded functions within "namespace std". The recent changes overload these functions at global scope. That is a bug.<br>
<br>
My tests are running now, and when they are complete I will propose the patch, but I can assure you that overloading global symbols from the C headers is not compliant with C++.<br>
<br>
MartinO<br>
<div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:metafoo@gmail.com">metafoo@gmail.com</a> [mailto:<a href="mailto:metafoo@gmail.com">metafoo@gmail.com</a>] On Behalf Of Richard Smith<br>
Sent: 23 January 2016 16:58<br>
To: <a href="mailto:Martin.ORiordan@movidius.com">Martin.ORiordan@movidius.com</a><br>
Cc: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] LibC++ v3.8 - Problems with ISO C wrapper headers<br>
<br>
Hi Martin,<br>
<br>
On 1/23/16, Martin J. O'Riordan via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> While getting our implementation of the compiler ready for v3.8 we<br>
> came across a significant problem in the new implementation of<br>
> LibC++'s handling of the ISO C Standard headers that needs to be fixed<br>
> before the v3.8 release.<br>
<br>
You're mistaken about a lot of the things you say below, but I agree that your example code ought to work, assuming that libc++ intends to support __fp16 (but I don't think it currently does). See the bottom of my mail for a suggestion of how to move forward with this.<br>
<br>
> We discovered the problem when running some tests that were derived<br>
> from real-world code. The initial example involved a C++ program<br>
> including '<math.h>' and using 'fabs' but the issue applies equally to<br>
> the other headers, for example:<br>
><br>
> #include <math.h><br>
><br>
> ...<br>
><br>
> __fp16 y; // We use FP16 a lot<br>
><br>
> fabs(y); // really -> fabs((double)y);<br>
><br>
> In C there is only one 'fabs' with the signature:<br>
><br>
> double fabs(double)<br>
<br>
That's largely irrelevant. In C++, <math.h> is a C++ standard library header, whose contents are specified by C++'s [c.math] and [depr.c.headers]. These say that <math.h> provides the same set of overloads in the global namespace that <cmath> provides in namespace std. libc++ has recently changed to implement this rule (that has<br>
*always* been part of the C++ standard). Thus your suggested approach to fixing this is not appropriate.<br>
<br>
> With the new implementation of the headers for LibC++, there is now a<br>
> file named 'c++/math.h' that includes the C version and then<br>
> supplements it for<br>
> C++. When I use this, the above use of 'fabs' above results in an<br>
</div></div>> C++overload<br>
<div class="HOEnZb"><div class="h5">> ambiguity error.<br>
><br>
> It's easy to say "It's C++, use '<cmath>'",<br>
<br>
That wouldn't help. In namespace std, libc++ has always provided overloads resulting in the ambiguity you're now seeing (and FWIW, this is the overload set required by the C++ standard).<br>
<br>
[...]<br>
> and has odd incongruities such as:<br>
><br>
> #include <math.h><br>
><br>
> float (*pf)(float) = std::fabs; // Okay, we have this<br>
> long double (*pld)(long double) = std::fabs; // Okay, we have this too<br>
> double (*pd)(double) = std::fabs; // Oops, no such function<br>
<br>
That seems a consequence of your (incorrect) patch. libc++'s current <math.h> doesn't provide any of these in namespace std, consistent with the requirements of the C++ standard. The intent is that no set of #includes gives you a partial overload set for any of these functions (except cases like 'abs', where C++ specifies that the overload set is split across multiple headers).<br>
<br>
<br>
The real issue is that libc++ doesn't support __fp16 (you should be able to observe this with both past versions of libc++ and with trunk if you change your testcase to use <cmath> and std::fabs). The right way to fix this would be to add __fp16 overloads to <math.h> (in the cases where the underlying compiler and language mode provide such a<br>
type) and ensure its __promote does the right thing for __fp16. It's up to the libc++ maintainers whether they consider this to be a regression and whether they'd accept a patch for it in the 3.8 release.<br>
<br>
But it's not a bug that libc++'s <math.h> now follows the C++ standard when compiling in C++ mode.<br>
--<br>
Richard<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>