This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Builtins in `std'



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]