This is the mail archive of the
mailing list for the GCC project.
Re: Builtins in `std'
>>>>> "Jason" == Jason Merrill <firstname.lastname@example.org> 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 email@example.com
CodeSourcery, LLC http://www.codesourcery.com