This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, Steve Ellcey <sellcey at mips dot com>, "Maciej W. Rozycki" <macro at linux-mips dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Thu, 22 Jan 2015 19:59:30 +0100
- Subject: Re: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.
- Authentication-results: sourceware.org; auth=none
- References: <1421951065 dot 4572 dot 47 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1501221832100 dot 29901 at digraph dot polyomino dot org dot uk>
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?