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: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: sellcey at imgtec dot com, Carlos O'Donell <carlos at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 22 Jan 2015 17:42:34 +0000 (GMT)
- 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> <1421947572 dot 4572 dot 37 dot camel at triegel dot csb>
On Thu, 22 Jan 2015, Torvald Riegel wrote:
> > 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?
N32 MIPS is an ILP32 ABI with 64-bit registers. So the `long long' type
and its derivatives use native 64-bit operations (that are atomic if
required) with no performance penalty, but the traditional (C89) C data
types are limited to 32 bits only. I gather this is GCC; I'd expect that
behaviour with GCC anyway.
Maciej