[Bug lto/56578] Testcase behaves differently when compiled with LTO

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56578

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|WAITING                     |NEW
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
      Known to fail|                            |4.6.4, 4.7.3, 4.8.0

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-12 09:51:51 UTC ---
Thanks.  With fixing the size_t issues of the testcase I can reproduce it
on x86_64 as well (original testcase reproduces with -m32).

We could say the bug is in the testcase.  Failing is:

gcc-4.8 -B /abuild/rguenther/trunk-g/gcc -flto -c func.c -o a.o
ar --plugin=/abuild/rguenther/trunk-g/gcc/liblto_plugin.so -cr libxxx.a a.o
gcc-4.8 -B /abuild/rguenther/trunk-g/gcc -flto main.c libxxx.a -o prog3
./prog3
FAIL

that's because you are providing an implementation of malloc in libxxx.a a.o
from func.c that does not have the C standards semantics.  You have to
compile this module with -fno-builtin-malloc (or -fno-builtins).

Honza: I believe we _should_ tell the linker that we have a definition of
malloc available, even if it is a "builtin".  That is, the testcase should
work as it is clearly well-defined on the linker side (setting aside that
GCC might still optimize the result in an unexpected way because it can
rely on malloc/free semantics).

Thus, confirmed as a bug in LTO symtab handling.