glibc 2.21 - Machine maintainers, please test your machines.
Commit Message
On Fri, Jan 23, 2015 at 4:11 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 3:13 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> On 1/23/2015 5:03 PM, H.J. Lu wrote:
>>>
>>> On Fri, Jan 23, 2015 at 1:32 PM, Carlos O'Donell <carlos@redhat.com>
>>> wrote:
>>>>
>>>> Dear Machine Maintainers,
>>>>
>>>> Please start testing your machines against glibc
>>>> master.
>>>>
>>>> Please update the glibc 2.21 release page with your
>>>> testing results:
>>>>
>>>> https://sourceware.org/glibc/wiki/Release/2.21
>>>>
>>>> If nobody objects I want to cut the release as soon
>>>
>>> x32 failed to build:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17870
>>
>>
>> tilegx32 failed to build with the same symptoms.
>>
>
> I checked in my fix. It should build for you now.
>
I checked in another fix.
Comments
On Fri, 2015-01-23 at 16:22 -0800, H.J. Lu wrote:
> On Fri, Jan 23, 2015 at 4:11 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Fri, Jan 23, 2015 at 3:13 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> >> On 1/23/2015 5:03 PM, H.J. Lu wrote:
> >>>
> >>> On Fri, Jan 23, 2015 at 1:32 PM, Carlos O'Donell <carlos@redhat.com>
> >>> wrote:
> >>>>
> >>>> Dear Machine Maintainers,
> >>>>
> >>>> Please start testing your machines against glibc
> >>>> master.
> >>>>
> >>>> Please update the glibc 2.21 release page with your
> >>>> testing results:
> >>>>
> >>>> https://sourceware.org/glibc/wiki/Release/2.21
> >>>>
> >>>> If nobody objects I want to cut the release as soon
> >>>
> >>> x32 failed to build:
> >>>
> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=17870
> >>
> >>
> >> tilegx32 failed to build with the same symptoms.
> >>
> >
> > I checked in my fix. It should build for you now.
> >
>
> I checked in another fix.
HJ, a fix for this was posted on Thursday already, and you had been CC'd
on it and replied. Please check that there's no difference between what
you patched and the proposed patch. (It's wait too late in my timezone
to do that now, but I'll do this tomorrow or so too.)
On Fri, Jan 23, 2015 at 5:43 PM, Torvald Riegel <triegel@redhat.com> wrote:
> On Fri, 2015-01-23 at 16:22 -0800, H.J. Lu wrote:
>> On Fri, Jan 23, 2015 at 4:11 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Fri, Jan 23, 2015 at 3:13 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>> >> On 1/23/2015 5:03 PM, H.J. Lu wrote:
>> >>>
>> >>> On Fri, Jan 23, 2015 at 1:32 PM, Carlos O'Donell <carlos@redhat.com>
>> >>> wrote:
>> >>>>
>> >>>> Dear Machine Maintainers,
>> >>>>
>> >>>> Please start testing your machines against glibc
>> >>>> master.
>> >>>>
>> >>>> Please update the glibc 2.21 release page with your
>> >>>> testing results:
>> >>>>
>> >>>> https://sourceware.org/glibc/wiki/Release/2.21
>> >>>>
>> >>>> If nobody objects I want to cut the release as soon
>> >>>
>> >>> x32 failed to build:
>> >>>
>> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=17870
>> >>
>> >>
>> >> tilegx32 failed to build with the same symptoms.
>> >>
>> >
>> > I checked in my fix. It should build for you now.
>> >
>>
>> I checked in another fix.
>
> HJ, a fix for this was posted on Thursday already, and you had been CC'd
> on it and replied. Please check that there's no difference between what
> you patched and the proposed patch. (It's wait too late in my timezone
> to do that now, but I'll do this tomorrow or so too.)
>
I checked:
https://sourceware.org/ml/libc-alpha/2015-01/msg00421.html
My patches are equivalent to yours.
@@ -5,6 +5,7 @@
with uint64_t.
* nptl/sem_waitcommon.c (__sem_wait_cleanup): Replace 1UL with
(uint64_t) 1.
+ (__new_sem_wait_fast): Replace unsigned long with uint64_t.
(__new_sem_wait_slow): Replace unsigned long int with uint64_t.
Replace 1UL with (uint64_t) 1.
* sysdeps/nptl/internaltypes.h (new_sem): Replace unsigned long
@@ -228,7 +228,7 @@ __new_sem_wait_fast (struct new_sem *sem, int
definitive_result)
and the failure path of the CAS. If the weak CAS fails and we need a
definitive result, retry. */
#if __HAVE_64B_ATOMICS
- unsigned long d = atomic_load_relaxed (&sem->data);
+ uint64_t d = atomic_load_relaxed (&sem->data);
do
{