Re: Help with fixing weak aliases

[Jim Wilson <wilson at specifixinc dot com>]

Roger Sayle wrote:
> I'm sorry to be a bother, but could someone who understands weak
> aliases, and more importantly how they're supposed to work in GCC
> take a look at my analysis attached to PR middle-end/11397?

I doubt that anyone understands this code well enough to solve the 
problem based on your analysis.

It would be useful to have the same analysis for gcc-3.1 that you 
already did for gcc-3.3.  Since we know gcc-3.1 works, and we know that 
gcc-3.3 does not work, if we compare the two code flows, it may then be 
obvious why gcc-3.3 does not work.

Alternatively, do a binary search to find the patch that broke this 
testcase.  If we know what patch broke this testcase, and we have the 
original testcase that justified the patch, we can figure out how to 
modify that patch to work for both the original testcase and this testcase.

So someone needs to do additional work before this can be fixed.

From a brief glance at the code, I see that assemble_alias sets 
TREE_USED, and weak_finish does nothing if TREE_USED is set, so that 
should be enough to prevent two .weakext directives from being emitted. 
 If that doesn't work, then maybe the decl that got put on the 
weak_decls list is somehow different from the decl that got passed to 
assemble_alias.  Maybe someone is reallocating decls without copying the 
TREE_USED flag?  Or maybe the fact that the decl got reallocated broke 
the weak_decls list?  I.e. the oldecl is on the weak_decls list, and the 
new decl got TREE_USED set which doesn't help.

This could perhaps be a side-effect of patches that tried to detect and 
warn for conflicting weak/alias/visibility attributes.

I suspect the key difference is that in gcc-3.1, handle_alias_attribute 
calls assemble_alias directly, whereas in gcc-3.3, the assemble_alias 
call gets deferred to rest_of_decl_compilation.  Find the patch that 
made that change, and take a closer look at it.

Maybe the place that is reallocating decls (duplicate_decls?) needs to 
scan the weak_decls list, and replace olddecl with newdecl there if we 
have a weak decl?

Or alternatively, maybe we should modify handle_weak_attribute the same 
way that handle_alias_attribute has already been modified, i.e. defer 
the declare_weak call until rest_of_decl_compilation?  Or maybe just the 
part that puts the decl on the weak_decls list, to ensure that 
weak_decls has the same decl that gets passed to assemble_alias?
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com