| Message ID | CAMe9rOpiTj2PTrA3xgFunhEtOjfmqAxNvpUnDzvd-LNeViWSiA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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.
diff --git a/ChangeLog b/ChangeLog index a59266f..306341c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -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 diff --git a/nptl/sem_waitcommon.c b/nptl/sem_waitcommon.c index c60daa3..311e511 100644 --- a/nptl/sem_waitcommon.c +++ b/nptl/sem_waitcommon.c @@ -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 {