This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Update to new generic semaphore algorithm v2
- From: Torvald Riegel <triegel at redhat dot com>
- To: sellcey at imgtec dot com
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 22 Jan 2015 18:26:12 +0100
- Subject: Re: [PATCH] Update to new generic semaphore algorithm v2
- Authentication-results: sourceware.org; auth=none
- References: <1421111716 dot 23151 dot 35 dot camel at triegel dot csb> <1421945655 dot 28889 dot 122 dot camel at ubuntu-sellcey>
On Thu, 2015-01-22 at 08:54 -0800, Steve Ellcey wrote:
> On Tue, 2015-01-13 at 02:15 +0100, Torvald Riegel wrote:
> > This patch is a revision of that patch:
> > https://sourceware.org/ml/libc-alpha/2014-12/msg00527.html
> >
> > OK?
>
> > 2015-01-13 Torvald Riegel <triegel@redhat.com>
> >
> > [BZ #12674]
> > * nptl/sem_waitcommon.c: New file. Implement new semaphore algorithm.
>
>
> Torvald, I think this patch has broken the MIPS build. I get a bunch
> of failures, they start with the new file (sem_waitcommon.c). It looks
> like some kind of 32/64 bit issue with the size of semaphores. Any
> ideas on how to fix this?
>
> In file included from ../sysdeps/nptl/lowlevellock.h:22:0,
> from ../nptl/descr.h:30,
> from ../sysdeps/mips/nptl/tls.h:73,
> from ../include/errno.h:27,
> from sem_waitcommon.c:20,
> from sem_wait.c:20:
> sem_waitcommon.c: In function ï~@~X__sem_wait_cleanupï~@~Y:
> sem_waitcommon.c:190:47: error: left shift count >= width of type
> [-Werror=shift-count-overflow]
> atomic_fetch_add_relaxed (&sem->data, -(1UL << SEM_NWAITERS_SHIFT));
> ^
> ../include/atomic.h:617:31: note: in definition of macro
> ï~@~Xatomic_fetch_add_relaxedï~@~Y
> __atomic_fetch_add ((mem), (operand), __ATOMIC_RELAXED); })
> ^
> sem_waitcommon.c: In function ï~@~X__new_sem_wait_slowï~@~Y:
> sem_waitcommon.c:267:11: error: left shift count >= width of type
> [-Werror=shift-count-overflow]
> 1UL << SEM_NWAITERS_SHIFT);
Do you use an LP64 data model? "1UL" is 64b if LP64, and
SEM_NWAITERS_SHIFT is 32. You could try 1ULL instead to see whether
that makes a difference.
The semaphore code uses the 64b version, because atomic.h thinks 64b
atomic ops are available.
Which compiler do you use?