[PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.

[Torvald Riegel]

On Thu, 2015-01-22 at 18:40 +0000, Joseph Myers wrote:
> On Thu, 22 Jan 2015, Torvald Riegel wrote:
> 
> > Also, do we already have any information on which data models we
> > support?  I reckon LP64 and ILP32?, or others as well?  I'd like to add
> > a comment to atomic.h, and if we have such information already, I'd just
> > point to it.
> 
> I believe we can assume: 8-bit char (may be signed or unsigned), 16-bit 
> short, 32-bit int, long either 32-bit or 64-bit and the same width as 
> pointers, long long 64-bit.

AFAICT, this leaves just LP64 and ILP32; ILP64, LLP64, and LP32 violate
at least one of your assumptions.

> But registers (and so syscall arguments) may 
> be 64-bit even with 32-bit long; architectures may vary about the 
> significance of high bits of function arguments and return values.
> 
> I could imagine there being a future glibc port where intmax_t is 128-bit 
> (with __int128 being a proper integer type rather than an extended type 
> that looks quite like an integer type but doesn't meet all the 
> requirements), although that's certainly outside the set of ABIs supported 
> by glibc at present (which expect intmax_t to be 64-bit like long long).
> 
> If code needs types of a given width (e.g. manipulating bits of a 
> floating-point number), it is of course good practice for it to use 
> <stdint.h> types rather than embedding assumptions that e.g. int means 
> 32-bit;

Looking at other glibc code, I had assumed that using uint32_t and
uint64_t wouldn't be current practice.  Are you saying that future
clean-up towards that (e.g., using uint64_t instead of "unsigned long
long" as in this patch) would be welcome?