Hit this while attempting to compile a large code base with WHOPR: tweak1.c: void y(void) { printf("y\n"); } void x(void) __attribute__((weak, alias("y"))); tweak2.c: void x(void) { printf("strong\n"); } tweak3.c: extern void x(void); int main(void) { x(); return 0; } Compile with gcc -fwhopr -c -O2 tweak1.c gcc -fwhopr -c -O2 tweak2.c gcc -fwhopr -c -O2 tweak3.c gcc -fwhopr tweak[123].o /tmp/ccGG7BOa.ltrans1.ltrans.o: In function `x': ccGG7BOa.ltrans1.o:(.text+0x0): multiple definition of `x' /tmp/ccGG7BOa.ltrans0.ltrans.o:ccGG7BOa.ltrans0.o:(.text+0x0): first defined here collect2: ld returned 1 exit status Without -fwhopr it works Version: Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/pkg/gcc-4.6-100607 --enable-checking=release --enable-languages=c,c++ --disable-nls --enable-lto --enable-gold --with-plugin-ld=/usr/local/bin/gold --with-elf-include=/usr/include/libelf Thread model: posix gcc version 4.6.0 20100607 (experimental) (GCC)
I noticed that setting -fwhole-program on both compile and link stage makes the weak problem go away. Expected?
(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.
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.
mine. testing patch.
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
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)
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
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.
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
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.
> 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
Honza, I think that is fixed now, correct? I should probably drop my workarounds but haven't yet
> 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
Andi, I suppose this is long fixed?
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.