Re: Builtins and C++ and such

[Mark Mitchell <mark at codesourcery dot com>]

> As I argued the first time we discussed this topic, it's not the library's

I guess I never got it the first time. :-)

> 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.

Valid point.  Of course, the library already knows other things about
the compiler (things like whether weak symbols work, and so forth),
but I agree that this is somewhat different.

But as long as we admit that V3 is always compiled with G++,
using __bulitins is as legitimate as any other GNUism.  And,
realistically, when is anyone going to be compiling V3 with a 
non-GCC-compatible compiler?

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

Hence my suggestion for fixincludes. :-)  Is this one actually
technically infeasible, or do we just not find it appealing?
(Doing it here doesn't dirty the interface...)

>> 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.

You at least still have to un-builtinize it when something else odd
happens, right?

If you see:

  extern "C" memcpy();

  ...

  extern "C" memcpy () { /* My own implementation goes here. */ }

we really don't want to use the builtin, do we?  So, we have to somehow
un-builtinize the existing declaration at that point.

I'm willing to implement my scheme, and that will resolve Mike's problem.
I don't have the same confidence that I can do your scheme as correctly,
so I'm nervous about that.  If you can convince me I should drop the
library approach, I'll go implement my scheme.  Is that fair?

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