This is the mail archive of the
mailing list for the GCC project.
Re: Help with fixing weak aliases
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 05 Jan 2004 21:37:45 -0800
- Subject: Re: Help with fixing weak aliases
- References: <Pine.LNX.email@example.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