This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Builtins in `std'
- To: Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr
- Subject: Re: Builtins in `std'
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 22 May 2001 23:48:27 -0700
- Cc: gcc at gcc dot gnu dot org, jason at cygnus dot com, bkoz at nabi dot net, gdr at codesourcery dot com, nathan at codesourcery dot com
- Organization: CodeSourcery, LLC
- References: <20010522200302Y.mitchell@codesourcery.com><flk8381sme.fsf@sel.cmla.ens-cachan.fr>
Those are driven by the necessacity of having ::fabs and std::fabs
referring to the same entity (ideally, the one provided by the C
library).
I understand. I expected that you would handle this in V3 by doing:
namespace std {
extern "C" double fabs (double);
}
Then, since you probably want to take advantage of the builtin
optimizations:
namespace std {
extern "C" inline double fabs (double d)
{ return __builtin_fabs (d); }
}
The mangled name of `std::fabs' will be `fabs' in this case, which is
right. So, I think the equality you are looking for will be there,
and the optimization will be there.
| ... For one thing, we accept the
| following entirely bogus program:
|
| void f() { std::fabs (3.0); }
|
| This isn't C, where `void f() { fabs (3.0); }' is a legal program.
Hmm, where is the problem?
It's not legal C++. Note that there is no `#include <math>' here; we
accept a program that talks about a function in the `std' namespace
without even declaring the namespace, let alone the function.
However, we need to ensure that `&::fabs == &std::fabs' evaluates to
true. On the other hand we have to overload fabs() in std:: only.
Right. Does my trick above work?
| There's no compatibility issue here, becuase we already broke:
|
| void f() { fabs (3.0); }
|
| by putting the builtins in the `std' namespace.
I don't think that is broken. Because any program which does the
above already says #include <math.h> whose effect is to make fabs
available in both :: and std::.
*If* you include `math.h'. I'm talking about the builtins that the
compiler creates without you including any headers.
| So, any objections to just not doing the insertion into `std'?
Yes. #include <cmath> puts fabs in std:: only.
I don't think this is relevant -- but I could be wrong. I *think*
we're talking at cross-purposes.
In particular, I'm trying to fix a regression on code like:
extern "C" double fabs (double) {}
namespace std {
double fabs (double) {}
}
(A user is allowed to do this; they might have a different library
implementation or something.)
These two functions get the same mangled name. The reason boils down
to the fact that the compiler implicitly declared `std::fabs', rather
than leaving that to the (most excellent) V3 headers to do.
To sum up, I think there's a different between C and C++. In C, we
want to make `fabs' a builtin, because uesrs are allowed to call it
without including the relevant headers. If we're going to optimize
it, we need to make it a builtin. However, in C++ you have to include
the header first, or you're not writing legal C++. And, that means
that the compiler doesn't need to predeclare the function.
Does that make more sense now?
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com