This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Builtins in `std'


A related question: should g++ put the builtins into global namespace
instead, perhaps with a different logic than in C (like it would become a
builtin only if a matching prototype in that scope has been seen)?

A lot of people use C headers in C++ code like:

#include <string.h>

int foo ()
{
  return strchr ("abc", 'a') != 0;
}

Now current g++ does not optimize this while it could.
Using inlines of all C builtins which would do:

extern "C" {
  inline char * strchr (const char *str, int c) { return __builtin_strchr (str, c); }
}

is problematic, since how would glibc find out which __builtin_* functions
exist in a particular g++ version and which don't?
Adding logic to make builtins appear on matching prototype would need some
hacking, but I don't think it would be that large, if people agree I could
write a patch for that.
Perhaps the same logic could be used for std, so std::strchr would be
optimized automatically if prototype has been seen, while std::fabs would
not, since it would not have extern "C" prototype and thus would not match.
Not putting the non-__builtin_ builtins into std:: has the drawback that
libstdc++ has to be sync with g++ builtins all the time (which is probably
not that hard for libstdc++ but hard for glibc).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]