http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994
Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian.huber@embedded-br | |ains.de --- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> 2013-03-20 09:20:24 UTC --- The crucial thing is also that all these functions are recognized as builtins and GCC knows what they are expected to do. The failure also vanishes if -fno-builtin is used. Lets have a look at this example: gcc 1.c 2.c 3.c -l4 I expect that the modules 1.o 2.o 3.o end up in the executable and unresolved symbols inside this module set are resolved with definitions provided by the library 4. In particular if I have a global function f() in 2.c then I expect to have this function in my executable even in case a global function f() is also defined in the library 4. This is wrong for builtins. Here GCC seems to assume that implementations are interchangeable. It would be quite interesting to know what happens if we compile libc with -flto. In one failed GCC test f() is memcpy(), 2.c is 20010124-1-lib.c and lib4 is libc.