I would like to compare the GCC builtin function memcpy versus the one one from libc. However, all iterations of -fno-builtin or -fno-builtin-memcpy seem to be ignored.
//g++ -O3 foo.cpp -S or
//g++ -O3 -fno-builtin foo.cpp -S
#include <string.h>
int main() {
volatile int n = 1000;
//int n = 1000;
float *x = new float[1000];
float *y = new float[1000];
memcpy(y,x,sizeof(float)*n);
//__builtin_memcpy(y,x,sizeof(float)*n);
}
What I have found is that if n in the source code above is not volatile then it inlines built-in code. However, when n is made volatile then it calls the function __memcpy_chk which is a version of memcpy with buffer overflow checking. If n is volatile and I instead call __builtin_memcpy then it calls memcpy.
So my conclusion so far is that the builtin code is only generated if n is known at compile time and that -fno-builtin is useless. I'm using GCC 4.8.2.
Is -fno-builtin obsolete? Is there a way to make GCC call memcpy from the C library even when n is known at compile time?
-fno-builtin and -fno-builtin-memcpy both have the effect you expected with gcc 4.9.1. This is probably just a bug in gcc 4.8.2; this particular combination of options is not widely used. -ffreestanding is a related switch that may have the effect you want with 4.8.2.
Note that the compiler is within its rights to optimize your program down to
int main() { return 0; }
when invoked without -fno-builtin(-memcpy) or -ffreestanding, even when n is volatile, as it can (in principle) prove that the program as a whole either has no observable side effects, or its behavior is undefined. (When n is not volatile, there cannot be UB; the UB happens if n is outside the range [0, 1000] when read, and volatile tells the compiler it can't assume n has the value written to it by the program.)