This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Only use 64b atomics in semaphores if long int is 64b.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Chris Metcalf <cmetcalf at tilera dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Sun, 01 Feb 2015 18:56:48 -0500
- Subject: Re: [PATCH] Only use 64b atomics in semaphores if long int is 64b.
- Authentication-results: sourceware.org; auth=none
- References: <1422647712 dot 16670 dot 41 dot camel at triegel dot csb>
On 01/30/2015 02:55 PM, Torvald Riegel 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
> 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.
> 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
Please aim for 2.22 as it needs a review of the SHLIB_COMPAT to make
sure it does what we intend.