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.
smime.p7s
Description: S/MIME cryptographic signature
