[Bug lto/44463] whopr does not work with weak functions

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2010.12.14 16:28:19
                 CC|                            |hubicka at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-14 16:28:19 UTC ---
mine. testing patch.

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-14 23:22:27 UTC ---
Author: hubicka
Date: Tue Dec 14 23:22:23 2010
New Revision: 167822

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167822
Log:
    PR lto/46940
    PR lto/44463
    * lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Construct nodes
    for aliases when they are used.

    * gcc.dg/lto/pr46940_0.c: New testcase.
    * gcc.dg/lto/pr46940_1.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/lto/pr46940_0.c
    trunk/gcc/testsuite/gcc.dg/lto/pr46940_1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lto-symtab.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-14 23:24:20 UTC ---
Note that the fix solves the problem just partly.  We now have duplicate
definition of the symbol with -fno-use-linker-plugin -flto-partition=1to1
This is because the problem in can_prevail predicate mentioned in the mail.
For this reason I left out the testcase from final commit (didn't noticed the
problem earlier since I tested it with plugin enabled only)

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |rguenther at suse dot de

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-07 00:52:34 UTC ---
Richi,
I am going to post alias fix that resolve most of breakness, but we still have
multiple decl problem with 1to1.

The reason is simple, there is 
void x(void) __attribute__((weak, alias("y"))); 
in one unit and
void x(void) { printf("strong\n"); }
in the other, so it is alias that gets prevailed by real function body. 
lto-symtab handles that but we end up with two declarations, one in cgraph (the
one with body) and other in alias pairs as those are not subject of merging.

I think when merging decls, we need to remove associated alias pairs too. 
lto-symtab is mostly yours, any idea how this can be best implemented?

Unasigning myself until this is discussed better.

Honza

Re: [Bug lto/44463] whopr does not work with weak functions

[Jan Hubicka]

actually it might be as easy as walking alias pairs after decl merging and
killing all pairs where decl has been replaced by different.  This probably can
be done at same time as we rewrite IL.

[Bug lto/44463] whopr does not work with weak functions

[hubicka at ucw dot cz]

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

--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-07 12:41:45 UTC ---
actually it might be as easy as walking alias pairs after decl merging and
killing all pairs where decl has been replaced by different.  This probably can
be done at same time as we rewrite IL.

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-09 02:11:27 UTC ---
Well, walking the alias pairs don't seem to be that easy after all. If I
understand it right, we first merge the decls and then read the alias pairs.
This means that we don't really have the information if the decl in question
was prevailed by decl from other file, right?

We really need to know that....

Honza

[Bug lto/44463] whopr does not work with weak functions

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2011-01-10 12:57:25 UTC ---
On Sun, 9 Jan 2011, hubicka at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
> 
> --- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-09 02:11:27 UTC ---
> Well, walking the alias pairs don't seem to be that easy after all. If I
> understand it right, we first merge the decls and then read the alias pairs.
> This means that we don't really have the information if the decl in question
> was prevailed by decl from other file, right?
> 
> We really need to know that....

Yep.  It's a mess.

I'd really really like to have aliases be handled in a unified
IPA symbol table entry facility before adding even more hacks.
Thus we'd have proper resolution information for them (hopefully)


Richard.

[Bug lto/44463] whopr does not work with weak functions

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> 2011-01-10 13:20:36 UTC ---
> Yep.  It's a mess.
> 
> I'd really really like to have aliases be handled in a unified
> IPA symbol table entry facility before adding even more hacks.
> Thus we'd have proper resolution information for them (hopefully)

Me too, but not for 4.6.  I spent some time thinking about implementation
of the symbol table and it is clear it won't be easy project at all.
Starting from "simple" problems like that our current target machinery makes
it impossible by not understanding ASM names to more involved issues how
to represent calls to aliases and thunks nicelly in cgraph without all
the problems we have.

We will also need to extend toplevel ASM syntax for a way specifying what
symbols are defined in them.

I plan to branch as soon as I will have some rest from fixing all the current
LTO issues.

Anyway my plan for this PR is to move streaming of alias pairs into lto-cgraph
(it is de-facto part of cgraph anyway) so they are read early enough.  Then
after decl merging but before fixup we can take care to remove the
non-prevailing weak aliases from the pair list.

I will do that once the other alias change settle unless someone stops me.

Honza

[Bug lto/44463] whopr does not work with weak functions

[andi-gcc at firstfloor dot org]

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

--- Comment #12 from Andi Kleen <andi-gcc at firstfloor dot org> 2011-10-07 05:52:08 UTC ---
Honza, I think that is fixed now, correct?

I should probably drop my workarounds but haven't yet

[Bug lto/44463] whopr does not work with weak functions

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> 2011-10-07 08:39:06 UTC ---
> Honza, I think that is fixed now, correct?
> 
> I should probably drop my workarounds but haven't yet

Yes, this one should be fixed with alias rewrite.  Please let me know if
dropping workarounds cause no troubles.  There are still some issues with
aliases left, I am just looking into weakrefs and then we need to handle
prevailance right on overwritten alias targets.
But the usual cases should just work.

Honza

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Andi, I suppose this is long fixed?

[Bug lto/44463] whopr does not work with weak functions

[andi-gcc at firstfloor dot org]

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

--- Comment #15 from Andi Kleen <andi-gcc at firstfloor dot org> ---
I don't have any aliasing problems currently, but I haven't tried to take out
the workarounds. But it's ok for me to close.

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

[Bug lto/44463] whopr does not work with weak functions

[andi-gcc at firstfloor dot org]

------- Comment #3 from andi-gcc at firstfloor dot org  2010-06-10 12:58 -------
On the link stage it's apparently not ignored and it fixes the weak
problem.

So just whatever weak magic -fwhole-program does would need to be done
when it's not enabled too.


-- 


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

[Bug lto/44463] whopr does not work with weak functions

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-10 12:29 -------
(In reply to comment #1)
> I noticed that setting -fwhole-program on both compile and link stage
> makes the weak problem go away. Expected?

No.  -fwhole-program is ignored during compile stage if -flto or -fwhopr
is specifed.


-- 


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

[Bug lto/44463] whopr does not work with weak functions

[andi-gcc at firstfloor dot org]

------- Comment #1 from andi-gcc at firstfloor dot org  2010-06-10 12:22 -------
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?


-- 


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