weakref miscompiling libgfortran
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.
That targetm.binds_local_p is no longer reliable is a serious bug.
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.
r~
typedef struct pthread_mutex_tag pthread_mutex_t;
extern int pthread_mutex_unlock (pthread_mutex_t *__mutex)
__attribute__ ((__nothrow__));
static __typeof(pthread_mutex_unlock) __gthrw_pthread_mutex_unlock
__attribute__ ((__weakref__("pthread_mutex_unlock")));
void foo(pthread_mutex_t *m)
{
__gthrw_pthread_mutex_unlock (m);
}
Gcc Register Allocation
Hello, There are some papers talking about the gcc register allocation in the summit proceedings. I'd like to know wether the graph coloring allocator has been used in the gcc-3.4.4. Also, where can I find some reference of the gcc register allocation, besides the source codes and summit proceedings. Thanks. Eric.
Re: Gcc Register Allocation
On 12/26/05, Eric Fisher <[EMAIL PROTECTED]> wrote: > Hello, > There are some papers talking about the gcc register allocation in the > summit proceedings. I'd like to know wether the graph coloring > allocator has been used in the gcc-3.4.4. Also, where can I find some > reference of the gcc register allocation, besides the source codes and > summit proceedings. > > Thanks. > Eric. > I hope this page would help you, http://gcc.gnu.org/wiki/RegisterAllocation -- Dueway
Re: weakref miscompiling libgfortran
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
Re: weakref miscompiling libgfortran
On Sun, Dec 25, 2005 at 07:36:16PM -0800, Geoff Keating wrote: > >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... It doesn't. Exchanging the TREE_PUBLIC check for the binds_local_p check was the first thing I tried. At which point I realized that we have Real Problems with this feature at the moment. r~
