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 t
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 consequ
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 regis
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 proceeding
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
