[Bug lto/46820] New: Undefined reference errors with LTO

[Bug lto/46820] New: Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

           Summary: Undefined reference errors with LTO
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: d.g.gorbachev@gmail.com
                CC: rguenth@gcc.gnu.org
              Host: i686-pc-linux-gnu
            Target: i686-pc-linux-gnu
             Build: i686-pc-linux-gnu


Created attachment 22654
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22654
Testcase for PR46820

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2010-12-06 13:17:13 UTC ---
Created attachment 22655
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22655
Generated code

$ make

/tmp/cckAaCxf.ltrans0.ltrans.o: In function `main':
cckAaCxf.ltrans0.o:(.text+0x7): undefined reference to `bar'
collect2: ld returned 1 exit status
make: *** [a] Error 1

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev <d.g.gorbachev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto

--- Comment #2 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2010-12-06 13:17:52 UTC ---
Another problem

$ make b

/tmp/ccELnMMN.ltrans1.ltrans.o: In function `main':
ccELnMMN.ltrans1.o:(.text+0x7): undefined reference to `foo'
collect2: ld returned 1 exit status
make: *** [b] Error 1

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #3 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2010-12-06 13:18:28 UTC ---
"make d" gives segmentation fault in lto_cgraph_replace_node. Like in PR44966,
PR46605.

[Bug lto/46820] Undefined reference errors with LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-06 13:43:25 UTC ---
This:

  __asm__(".weak\tfoo\n\t.set\tfoo,bar");

requires you to put __attribute__((used)) on bar.

Does it really require so many files?  I suppose -flto-partition=1to1 could
help reducing it (it will partition into ltrans files according to original
source files).

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev <d.g.gorbachev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22654|0                           |1
        is obsolete|                            |
  Attachment #22655|0                           |1
        is obsolete|                            |

--- Comment #5 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2010-12-06 17:40:44 UTC ---
Created attachment 22661
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22661
Reduced testcase for bug in comment #2

gcc -flto -flto-partition=1to1 *.c

Bug in comment #1 seems to be invalid. I cannot reproduce it with
__attribute__((used)).

[Bug lto/46820] Undefined reference errors with LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.07 11:50:31
     Ever Confirmed|0                           |1

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-07 11:50:31 UTC ---
The problem is we partition the toplevel asm away from the function it is
refering to.

int __attribute__((used)) bar(void)
{
  return 0;
}
__asm__(".weak\tfoo\n\t.set\tfoo,bar");

bar ends up in a different partition than the asm which then of course
doesn't work.

I'm not sure we can do much about this.  Aliases via toplevel asms
(or toplevel asms in general) are hard to deal with with WHOPR.

Honza, any ideas?

The testcase seems to work fine using the linker-plugin and gold, btw.
Not sure if by design or only by chance though.  We definitely get
different partitioning - which shouldn't happen with 1to1 partitioning, no?

[Bug lto/46820] Undefined reference errors with LTO

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> 2010-12-11 13:31:21 UTC ---
> int __attribute__((used)) bar(void)
> {
>   return 0;
> }
> __asm__(".weak\tfoo\n\t.set\tfoo,bar");
> 
> bar ends up in a different partition than the asm which then of course
> doesn't work.
> 
> I'm not sure we can do much about this.  Aliases via toplevel asms
> (or toplevel asms in general) are hard to deal with with WHOPR.

Yes, they are.  I think only way to make this work is to use externally_visible
attribute.  I did that at Mozilla side.
> 
> Honza, any ideas?
> 
> The testcase seems to work fine using the linker-plugin and gold, btw.

I think it is just because gold ignore some linker errors after plugin
execution.
> Not sure if by design or only by chance though.  We definitely get
> different partitioning - which shouldn't happen with 1to1 partitioning, no?

We still mangle the name of bar I think into bar.local.xyz.
We also do not track sources of __asm__ statements and simply drop them all
into first
partition.  We can add lto_file handle and make partitioning code to deal with
them,
but it is not going to win us much, as requiring 1to1 for toplevel asms is bad
idea anyway.

Honza

[Bug lto/46820] Undefined reference errors with LTO

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2010-12-11 15:03:44 UTC ---
Note that while working on mozilla, I noticed that SUN's compiler extends the
toplevel asm syntax by allowing parameters (and the usual %n references to
them).  It probably makes sense to adopt this syntax in future.  Until then
Iguess we will need to explain users that toplevel asm statements basically
exists outside of LTO unit and thus everything used by them needs to be marked
as externally visible.

Honza

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #9 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2010-12-13 22:02:02 UTC ---
Marking bar() externally_visible does not help..

[Bug lto/46820] Undefined reference errors with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-14 10:27:03 UTC ---
__asm__(".weak\tfoo\n\t.set\tfoo,bar");
sets FOO as equivalent of BAR. I guess this breaks when asm ends up in
different partition than BAR and also leads to undefined symbols when LTO
symtab is used since that one does not define any of symbols defined in asm
statements.

I am affraid that there is currently no way to make such asm statement LTO
friendly and also that we are quite broken WRT symbols defined in the asm
statements (I guess I didn't see this with Mozilla since it is shared library).

Isn't there function attribute that does the same as your asm statement?

[Bug lto/46820] Undefined reference errors with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-14 10:46:48 UTC ---
... I meat weakref attribute.

[Bug lto/46820] Undefined reference errors with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #12 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2010-12-15 00:15:24 UTC ---
It's weak, alias("...").

"At present, a declaration to which weakref is attached can only be static."

[Bug lto/46820] toplevel ASM statements should be allowed to reffer local symbols in LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Undefined reference errors  |toplevel ASM statements
                   |with LTO                    |should be allowed to reffer
                   |                            |local symbols in LTO
           Severity|normal                      |enhancement

[Bug lto/46820] toplevel ASM statements should be allowed to reffer local symbols in LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-05-11 22:38:23 UTC ---
Updated description to match reality. Here it should really be user defined
alias with weak visibility.
void __f () { /* Do something. */; }
void f () __attribute__ ((weak, alias ("__f")))
works as expected.

But still toplevel asm statements should be allowed to have list of used and
defined symbols.  I think there was patch circulating for this. But this is an
enhancement request.  The asm statement as written has no chance to work unless
GCC gets into busyness of parsing assembly.

Honza

[Bug lto/46820] toplevel ASM statements being moved away from the functions in the TU

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mliska at suse dot cz

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 57703 has been marked as a duplicate of this bug. ***

[Bug lto/46820] toplevel ASM statements being moved away from the functions in the TU

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kloczko.tomasz at gmail dot com

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 111964 has been marked as a duplicate of this bug. ***