On 27/12/2005, at 3:36 PM, Jakub Jelinek wrote:
On Tue, Dec 27, 2005 at 02:20:44PM -0800, Geoff Keating wrote:
I'm not sure what "just fine" definition you're using here. I don't
think you can say it's been extensively tested, and I'm fairly sure I
can find a bunch of bugs in it. I have alr
> > I still support a reverting of the weakref patch as it was put way too
> > late
> > for 4.1 (stage 3 is not a good idea for a new feature).
>
> Depends on if you consider it a new feature or a bug fix.
>From my perspective, this patch introduced more bugs than it fixed:
http://gcc.gnu.org/b
On Dec 28, 2005, at 4:33 AM, Jakub Jelinek wrote:
I still support a reverting of the weakref patch as it was put way too
late
for 4.1 (stage 3 is not a good idea for a new feature).
Depends on if you consider it a new feature or a bug fix.
It was a new feature to work around a bug which is o
On Tue, Dec 27, 2005 at 06:39:58PM -0500, Andrew Pinski wrote:
>
> On Dec 27, 2005, at 6:36 PM, Jakub Jelinek wrote:
> >It has nothing to do with libgfortran actually, libgfortran only ever
> >uses the weak pthread function aliases within libgfortran.
> >The reason why weakref attribute has been a
On Dec 27, 2005, at 6:36 PM, Jakub Jelinek wrote:
It has nothing to do with libgfortran actually, libgfortran only ever
uses the weak pthread function aliases within libgfortran.
The reason why weakref attribute has been added is primarily libstdc++,
see PR4372, because unlike libgfortran or lib
On Tue, Dec 27, 2005 at 02:20:44PM -0800, Geoff Keating wrote:
> I'm not sure what "just fine" definition you're using here. I don't
> think you can say it's been extensively tested, and I'm fairly sure I
> can find a bunch of bugs in it. I have already filed one as gcc.gnu.org/bugzilla/show
On 27/12/2005, at 1:49 AM, Jakub Jelinek wrote:
On Mon, Dec 26, 2005 at 11:34:16PM -0800, Geoff Keating wrote:
We've had Real Problems with this feature since it was introduced. I
expect it'll take at least another two or three months before it
settles down and starts to work on most targets
>
> On Mon, Dec 26, 2005 at 11:34:16PM -0800, Geoff Keating wrote:
> > We've had Real Problems with this feature since it was introduced. I
> > expect it'll take at least another two or three months before it
> > settles down and starts to work on most targets; that's only to be
> > expecte
On Mon, Dec 26, 2005 at 11:34:16PM -0800, Geoff Keating wrote:
> We've had Real Problems with this feature since it was introduced. I
> expect it'll take at least another two or three months before it
> settles down and starts to work on most targets; that's only to be
> expected for such a
On 25/12/2005, at 8:51 PM, Richard Henderson wrote:
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
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
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
13 matches
Mail list logo
