On 02/15/2016 07:13 AM, Florian Weimer wrote:
On 02/15/2016 03:21 AM, Martin Sebor wrote:
On 02/12/2016 04:55 AM, Florian Weimer wrote:
For the C++ compilers version which recognize memcpy, is there a
difference between calling memcpy via your own extern "C" declaration,
and calling __builtin_memcpy?
Except in freestanding mode (with builtins disabled) I don't believe
there is a difference. They both get expanded the same way (either
inline or to a call to memcpy depending on arguments).
Hmm. I tried to verify this using:
I would expect the other string builtins to be treated the same
as memcpy although I don't think gcc provides the required C++
overloads of functions like strchr.
#include <stddef.h>
extern "C" size_t strlen(const char*);
extern "C" char *strchr(const char *, char);
Though it shouldn't matter here, strchr takes an int as the second
argument.
const char *search(const char *, int) __asm__ ("strchr");
size_t
call_strchr_0 (char *s)
{
return strlen(strchr(s, 0));
}
size_t
call_strchr_1 (char *s)
{
extern char *strchr(char *, char);
This is a declaration of some C++ function strchr, unrelated to C
strchr. It's not possible to declare a function with C language
linkage in C++ function.
size_t
call_builtin (const char *s)
{
return strlen(__builtin_strchr(s, 0));
}
Only the last call in call_builtin is optimized with the knowledge of
the meaning of the strchr function.
I don't see a difference between it and call_strchr_0. How is it
optimized differently and for what target (and with what options)?
I'm trying to determine what to use as the best possible fix for this
glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=19618
I'm wondering if I should switch to a __builtin-based approach for GCC,
and the extern hack for non-GCC compilers.
Not having tried it or even thought about it too carefully, Richard's
suggestion makes sense to me (the __call_memchr function outlined in
the bug is etxern "C"). Does it not work?
Martin
