Re: C++: Difference between calling memcpy and __builtin_memcpy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux