This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with fixing weak aliases

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,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]