Builtins and C++ and such

[Mark Mitchell <mark at codesourcery dot com>]

Mike Stump recently busted my chops about the fact that:

  #include <memory.h>
  int main() { memcpy(...); }

doesn't get optimized to a builtin in C++.

I've recently reviewed the twenty-odd email messages that were
traded back and forth when I checked this change in, and can
reconstruct why we did this: the compiler had correctness problems,
including some correctness regressions, relating to treating
user-defined functions as builtins, and so forth.

The bottom line is that I'd still really rather see this fixed in
the headers (where it's easy to do:

  extern "C" inline memcpy() { __builtin_memcpy(); }

) that have special gunk in the compiler.

But, it's true that right now fixincludes doesn't do this, and our
C++ library doesn't have C headers that do this, so I guess we need
to do something.  (It would be nice if glibc did this, but it doesn't
matter since we need to do something good on non-GNU platforms too.)

I believe there are (at least) three plausible alternatives.
(Reverting my patch is not among these; it fixed real problems
in a sensible way.)  They are:

1. V3 C headers that do this.  Benjamin, what is the current status
   of the C headers in V3?  Is this technologically plausible, given
   the current state?

2. Fixincludes.

3. A change to expand_expr (in the CALL_EXPR) case to do a
   language-dependent analysis of whether or not the called function
   is a builtin.

   (Previously, we've done this with magic declarations, but this is
   foolish; that leads to problems keeping track of which are which,
   and whether or not they've really been declared, and so whether
   or not we should give errors and so forth.)

   The check, by default, would be the old way: look at the DECL.

   For C++, it would be something like:

   - Is the function extern "C"?

   - And does it have a name that we know corresponds to a builtin?

   - And is it undefined in this translation unit?  (It makes no
     sense to treat an actual *implementation* of memcpy as
     __builtin_memcpy.)

   For bonus points, we might do:

   - And is the type what we expect?  If not, we could not do the
     optimization and/or issue a warning.

   This approach does not make symbol-table processing any more
   complex; it can be done in a little self-contained function.

My preference is in the order that they appear on the list, i.e.,
do it in V3, if not that do this via fixincludes, if not that do
the compiler uckiness.  However, I'm only confident that the last
approach is technologically doable.

Thoughts?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com