From patchwork Fri Jan 23 22:13:21 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 4785 Received: (qmail 17375 invoked by alias); 23 Jan 2015 22:13:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 17342 invoked by uid 89); 23 Jan 2015 22:13:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f42.google.com MIME-Version: 1.0 X-Received: by 10.60.134.200 with SMTP id pm8mr5975924oeb.61.1422051201806; Fri, 23 Jan 2015 14:13:21 -0800 (PST) In-Reply-To: <54C2C6E4.3020401@redhat.com> References: <54C2BDD7.7000304@redhat.com> <54C2C6E4.3020401@redhat.com> Date: Fri, 23 Jan 2015 14:13:21 -0800 Message-ID: Subject: Re: glibc 2.21 - Machine maintainers, please test your machines. From: "H.J. Lu" To: "Carlos O'Donell" Cc: GNU C Library On Fri, Jan 23, 2015 at 2:10 PM, Carlos O'Donell wrote: > On 01/23/2015 05:03 PM, H.J. Lu wrote: >> On Fri, Jan 23, 2015 at 1:32 PM, Carlos O'Donell 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 > > Thanks, I'll look into this immediately. > > Cheers, > Carlos. > > I am testing this and will check it in after testing it on x32, x86-64 and ia32. diff --git a/nptl/sem_post.c b/nptl/sem_post.c index 9162e4c..6e495ed 100644 --- a/nptl/sem_post.c +++ b/nptl/sem_post.c @@ -65,7 +65,7 @@ __new_sem_post (sem_t *sem) added tokens before (the release sequence includes atomic RMW operations by other threads). */ /* TODO Use atomic_fetch_add to make it scale better than a CAS loop? */ - unsigned long int d = atomic_load_relaxed (&isem->data); + uint64_t d = atomic_load_relaxed (&isem->data); do { if ((d & SEM_VALUE_MASK) == SEM_VALUE_MAX) diff --git a/nptl/sem_waitcommon.c b/nptl/sem_waitcommon.c index 96848d7..c60daa3 100644 --- a/nptl/sem_waitcommon.c +++ b/nptl/sem_waitcommon.c @@ -187,7 +187,7 @@ __sem_wait_cleanup (void *arg) #if __HAVE_64B_ATOMICS /* Stop being registered as a waiter. See below for MO. */ - atomic_fetch_add_relaxed (&sem->data, -(1UL << SEM_NWAITERS_SHIFT)); + atomic_fetch_add_relaxed (&sem->data, -((uint64_t) 1 << SEM_NWAITERS_SHIFT)); #else __sem_wait_32_finish (sem); #endif @@ -263,8 +263,8 @@ __new_sem_wait_slow (struct new_sem *sem, const struct timespec *abstime) #if __HAVE_64B_ATOMICS /* Add a waiter. Relaxed MO is sufficient because we can rely on the ordering provided by the RMW operations we use. */ - unsigned long d = atomic_fetch_add_relaxed (&sem->data, - 1UL << SEM_NWAITERS_SHIFT); + uint64_t d = atomic_fetch_add_relaxed (&sem->data, + (uint64_t) 1 << SEM_NWAITERS_SHIFT); pthread_cleanup_push (__sem_wait_cleanup, sem);