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

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

[d.g.gorbachev at gmail dot com]

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

             Bug #: 56578
           Summary: Testcase behaves differently when compiled with LTO
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: d.g.gorbachev@gmail.com


Created attachment 29625
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29625
Testcases

The last testcase prints "FAIL". gcc-nm says "no symbols" in the object file
(a.o).

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-03-11
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-11 10:30:13 UTC ---
Hmm, it works for me both with 4.7 and trunk.  And

rguenther@murzim:/tmp> gcc-nm-4.7 a.o
00000000 T malloc
rguenther@murzim:/tmp> gcc-nm-4.8 a.o
00000000 T malloc

I'm using GNU ld 2.23.1.  Even with gold 2.23.1 it works for me
(that is, 'make' prints three times OK).  glibc 2.14.1, x86_64-linux.

Can you elaborate on your configuration?

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

[d.g.gorbachev at gmail dot com]

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

--- Comment #2 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2013-03-12 00:46:13 UTC ---
GCC 4.8.0, 4.7.3, 4.6.4; build = host = target = i686-pc-linux-gnu; configured
with "--enable-languages=c,c++ --enable-version-specific-runtime-libs
--disable-nls --disable-shared"; glibc 2.17; recent binutils (GNU ld and gold).

> that is, 'make' prints three times OK

The 4th time (prog3) it prints "FAIL" for me -- free() is from main.c, but
malloc() is from glibc.

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

[rguenth at gcc dot gnu.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.

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

[d.g.gorbachev at gmail dot com]

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

--- Comment #4 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2013-03-12 13:30:30 UTC ---
> We could say the bug is in the testcase.  Failing is:
[...]
> 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.

The TC is invalid but it is not buggy, gcc-nm could not even find the "malloc"
symbol in a.o

> You have to compile this module with -fno-builtin-malloc
> (or -fno-builtins).

It is not enough to compile just func.c with -fno-builtin(-malloc), as one
might expect. I have to use it for main.c as well.

> GCC might still optimize the result in an unexpected way
> because it can rely on malloc/free semantics

There is a "volatile" modifier in the TC. It should inhibit such optimizations,
I think?

[Bug lto/56578] Testcase behaves differently when compiled with LTO (builtin for malloc is not getting the right one)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Testcase behaves            |Testcase behaves
                   |differently when compiled   |differently when compiled
                   |with LTO                    |with LTO (builtin for
                   |                            |malloc is not getting the
                   |                            |right one)

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I remember seeing another bug that is very similar issue with respect to
builtins.