C inlines that are also builtins.

[Martin Sebor]

>> If I understand correctly it sounds to me like what you're looking
>> for is the opposite of what I requested in bug 59219 in a slightly
>> different context. By defining a function like memcpy inline and
>> in terms of __builtin__memcpy_chk GCC expands it inline when it
>> can even when -fno-builtin is used. The bug suggests to change
>> it but since it's not been implemented (yet) and may never be it
>> should be possible to rely on the current behavior.
>
> Dunno if it's opposite or not as I don't quite understand you case. Most
> probably it's ortogonal to what I need.
>
> I need to be able to port particular code that works with -std=gnu89
> compilation mode to -std=gnu99 or -std=gnu11. This code uses its own
> implementation of libc/libm that heavily uses "extern inline" for
> standard functions. Right now this task seems to be close to
> imopossible, as GCC builtins are always (implicitly) declared as if
> -std=gnu89 mode were active. I.e., builtins seem to implicitly get
> "extern inline" declaration, while in -std=gnu99 and above modes they
> rather should be declared "inline".

I was suggesting a workaround until gcc is fixed, one that should
let you benefit from the gcc intrinsics while using -fno-builtin
or -ffreestanding.

For example, defining memcpy like this in a header:

   inline __attribute__ ((always_inline, artificial)) void*
   memcpy (void* restrict d, const void* restrict s, size_t n) {
       return __builtin___memcpy_chk (d, s, n, __builtin_object_size (d, 
1));
   }

makes it possible to include it in more than one translation unit
in the same program compiled with either of the two options and
benefit from the builtins. The program will also benefit from
the buffer overflow checking done by GCC. What you will need to
do in your libc is define __memcpy_chk and handle the runtime
buffere overflow detection when you can before forwarding the
call to your own memcpy.

Martin