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.
