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.

Reply via email to