[PATCH] Only use 64b atomics in semaphores if long int is 64b.

[Torvald Riegel]

This patch is another attempt at fixing this.  It uses Josephs
suggestion for a new flag, SEM_USE_64B_ATOMICS, which is set to 1 iff
__HAVE_64B_ATOMICS != 0 and defined (__LP64__).  This is meant to
capture the condition that we need "long int" to be a 8-byte-sized type.

This does expect that an 8B-sized long int will also be 8B-aligned.  Do
we support any arch where this isn't true?

Joseph also suggested to !SHLIB_COMPAT (libpthread, GLIBC_2_0,
GLIBC_2_22)) to enable this on archs for which support has been added
starting with 2.22.  I'm not entirely sure how this machinery works
(specifically, where/how an arch defines what it's first supported
version is), but I'll prepare a patch that uses this in the struct
new_sem definition and tries to merge the many bits/semaphore.h headers
into a generic one (so that new archs would pick up this one
specifically).

Chris' patch for at-runtime realignment of the data can still be added
during the 2.22 cycle.  I talked a bit about it with Carlos offline, and
one concern he had was violating the aliasing rules in the language, and
thus potentially making the compiler do funny things (hence the
hesitation to use this for 2.21).

Tested on x86_64-linux and i686-linux.

OK?

Carlos, if OK, do you want this for 2.21, or for 2.22 (and let all
affected archs just set __HAVE_64B_ATOMICS to 0 as MIPS has done
already)?

(Will add changelog later.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sem-nonlp64.patch
Type: text/x-patch
Size: 5328 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150130/f03c42e7/attachment.bin>