https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #15 from Andi Kleen ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
Jan Hubicka changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #14 from Jan Hubicka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #13 from Jan Hubicka 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
droppin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #12 from Andi Kleen 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #11 from Jan Hubicka 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 resolut
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #10 from 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 2011-01-09
> 02:11:27 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #9 from Jan Hubicka 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #8 from Jan Hubicka 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 rewr
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #6 from Jan Hubicka 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_prev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #5 from Jan Hubicka 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
--- 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
--- 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
i
--- 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
17 matches
Mail list logo
