This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: powerpc pthread_once bug fix
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Alan Modra <amodra at gmail dot com>, libc-alpha at sourceware dot org
- Date: Tue, 25 Sep 2012 16:08:57 -0500
- Subject: Re: powerpc pthread_once bug fix
- References: <20120711113606.GM3117@bubble.grove.modra.org><503FB9AA.7000708@redhat.com><1346357129.4800.10.camel@spokane1.rchland.ibm.com><503FC962.5000305@redhat.com><1346360987.4800.11.camel@spokane1.rchland.ibm.com><503FDF1F.5050008@redhat.com><20120830225901.GF3159@bubble.grove.modra.org><20120830232027.GG3159@bubble.grove.modra.org><504040D2.9090802@redhat.com>
On Thu, Aug 30, 2012 at 11:42 PM, Jeff Law <law@redhat.com> wrote:
> On 08/30/2012 05:20 PM, Alan Modra wrote:
>>
>> On Fri, Aug 31, 2012 at 08:29:01AM +0930, Alan Modra wrote:
>>>
>>> I wrote this code in the first instance using atomic_read_barrier
>>> followed by atomic_increment.. The reason why I implemented the patch
>>> as I did, is that the asm allows MUTEX_HINT_REL on lwarx. Otherwise
>>> the asm is identical to atomic_read_barrier followed by
>>> atomic_increment. Please look at the generated object code to verify
>>> this is so (or to refute my claim and hopefully find why things are
>>> going wrong). Is UP defined for your builds?
>>
>>
>> Sigh. I see the error. "=&r" (tmp) needs to be "=&b" (tmp), because
>> "addi 0,0,1" is really "li 0,1".
>
> Build looks good. The testcase which had me looking at this issue is also
> looking good -- certianly far more iterations without tripping any problems
> than it's done before.
>
> Having looked at the patch fairly closely, I think it ought to go in once
> the constraint think is fixed.
I re-tested the patch with the modified constraint and it now passes
make check (whereas it used to hang in some tests).
I'll commit the patch shortly.
Ryan S. Arnold