Re: Builtins and C++ and such

[Jason Merrill <jason at redhat dot com>]

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

> But as long as we admit that V3 is always compiled with G++, using
> __bulitins is as legitimate as any other GNUism.

If there were some library-motivated reason for the library to use
__builtins, it would be legitimate.  But this would just be asking the
library to act as an intermediary between the compiler and itself.

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

Doing anything with fixincludes is unappealing.  And it tends to be more
complicated and fragile than you first expect, due to the variety of wacky
headers out there.

Basically, what we are trying to express is that the compiler knows special
things about certain functions; the logical place to express that is in the
compiler.  Anything else seems over-engineered.

I further think that this information should be expressed as annotations on
the declarations for those functions, just as if the declarations in the
headers were declared pure or noreturn or whatever.  If you try to hook in
later, I'm afraid you'll end up duplicating the work of code that already
knows to check DECL_BUILT_IN_CLASS, TREE_THIS_VOLATILE or whatever.  Code
duplication is bad.

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

Yes, but duplicate_decls already handles that.

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

I suppose so.  He who writes the code makes the rules...

Jason