Re: weakref miscompiling libgfortran

[Geoff Keating <geoffk at geoffk dot org>]

On 25/12/2005, at 3:08 PM, Richard Henderson wrote:

> This test case, simplified from libgfortran, currently results in a
> tail call to pthread_mutex_unlock on i686 with -fpic, and is the cause
> of all the libgomp fortran failures on the branch.  That this isn't
> seen on mainline is simply a consequence of not using any threadded
> fortran code on mainline.

It looks like ix86_function_ok_for_sibcall is using !TREE_PUBLIC as a  
proxy for 'does not call through the PLT', which is not right;  
probably it should be using binds_local_p instead, although it's  
possible that some calls to binds_local_p symbols are going through  
the PLT even though they don't need to.

> That targetm.binds_local_p is no longer reliable is a serious bug.

What's wrong with it?  It should be answering 'false' for a weakref,  
because the underlying object to which it refers might not be local  
(even though this particular name for the object is local).

When thinking about aliases there's a fundamental difference between  
the definition of TREE_PUBLIC, which only talks about names, and the  
definition of binds_local_p, which also talks about objects.

> And unless GeoffK can be convinced that the current setting of
> TREE_PUBLIC is in fact ON, then we'll have to audit every single
> use of that symbol, and determine if it actually should be testing
> targetm.binds_local_p, or some new predicate yet to be determined.

(I presume you meant 'correct' not 'current'.)

You can't avoid looking at every use of TREE_PUBLIC just by saying  
that TREE_PUBLIC should be set to true.  There are places that are  
expecting the documented definition of TREE_PUBLIC to hold, and won't  
work right if weakrefs are marked as TREE_PUBLIC even though they're  
not; for instance, in the IMA name-resolution logic, and in the stabs  
output code.

Attachment: smime.p7s
Description: S/MIME cryptographic signature