Builtins in `std'

[Mark Mitchell]

>>>>> "Jason" == Jason Merrill <jason_merrill@redhat.com> writes:

    Jason> This is where I disagree.  I don't think the V3 people
    Jason> should have to worry about this stuff.  For one thing, it
    Jason> interferes with the goal of writing a portable library.

Portable to other compilers?  It already ain't. :-) In fact, it's not
close, and the interactions with the C header stuff is going to be
especially hard to write portably.

This particular case is actually probably one of the easiest places to
be portable; you just have a file full of `#define __builtin_strchr
::strchr' (or equivalent `extern "C"' declaration in a magic hidden
namespace, or whatever) under `#ifndef __GNUC__' and you're all set.
Compared to the other machinations that we'll have to go through to
make the library work with other compilers, this one's a snap.

    Jason> Currently, when we declare a function, we look to see if
    Jason> it's a known nothrow C library function.  I'm suggesting
    Jason> that we can also look for a builtin handler, or
    Jason> noreturn-ness, or whatever other magic we want to know
    Jason> about a function, and set them up in the same code.

That sounds like a clever idea, and useful in general.

I don't want to solve all the problems all at once, necessarily, but I
do want to fix the numerous regressions we've got here since 2.95.

I remain convinced that the way to do this is to remove the builtins
from `std' (a two-liner), and change the library to use `__builtin'
(mechanical).  Going forward in 3.1, we then make it utterly illegal
to mnually redeclare/redefine a `__builtin' function, and then remove
all kinds of (broken) code from duplicate_decls, and life becomes just
a little bit better. :-)

If you and Jakub and Joseph want to do some way-snazzy bit later that
magically conjures up DECL_BUILTIN when appropriate, and that actually
seems better than just `#define __builtin_strchr ...' in a header file
for V3, then I sure won't stand in your way. :-) :-)

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