Re: Builtins and C++ and such

[Jason Merrill <jason at redhat dot com>]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

> --On Tuesday, March 19, 2002 10:53:46 PM +0000 Jason Merrill
> <jason@redhat.com> wrote:

>> I think special gunk in the compiler is necessary;

> Why?  (Not meant to be a rhetorical question; I'm curious.)

> Certainly, __builtin_memcpy is necessary -- but why gunk to turn
> memcpy into __builtin_memcpy?  Isn't that something the library
> headers can do for you, at least in C++ where you *had* to have
> a declaration?  Do we really care about people who manually write
> the declaration themselves?

As I argued the first time we discussed this topic, it's not the library's
job to know what functions the compiler has builtins for.  The only thing
that should need to know that is the compiler.  IMO, asking the library to
handle this dirties the interface between compiler and library.

And besides, we don't control the C headers on most targets.

> Of the various in-the-compiler schemes, my priorities would be:

> 1. Changes that are safest: i.e., least likely to result in
>    non-conforming and/or suprising results.
> 2. Changes that support multiple languages.
> 3. Changes that are easy to make, and self-contained.

> My beef with DECL_ANTICIPATED_P, and maybe your scheme, involve all
> of these problems: you have to remember to check DECL_ANTICIPATED_P,
> and you don't really know where all the places are, it doesn't do
> anything for you in Java or other languages, and, since there are
> multiple places to change, you have to change them all.

I don't think these apply to my scheme any more than yours; I think that it
could work fine as, say, a maybe_builtinize_fndecl entry point in
builtins.c.  Of course, separating this code from the frontend makes it
harder to examine the type or the extern "C"-ness of a decl, but certainly
not impossible.

Jason