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.
