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

[H.J. Lu]

On Fri, Jan 30, 2015 at 11:55 AM, Torvald Riegel <triegel@redhat.com> wrote:
> 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)?
>
>

After looking over the semaphore core, I decided to use 64-bit
atomics in semaphore for x32 and pay the extra cycle.  Please
define SEM_USE_64B_ATOMICS for x32.

Thanks.

-- 
H.J.