This is the mail archive of the
mailing list for the glibc project.
Re: __HAVE_64B_ATOMICS and alignment
- From: Florian Weimer <fweimer at redhat dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 27 Nov 2016 12:33:43 +0100
- Subject: Re: __HAVE_64B_ATOMICS and alignment
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com>
On 11/26/2016 09:52 PM, Andreas Schwab wrote:
On Nov 26 2016, Florian Weimer <firstname.lastname@example.org> wrote:
I'm describing the background for this question. The opaque sem_t
definition looks like this:
long int __align;
But the __HAVE_64B_ATOMICS definition of the non-opaque version looks like
This means that for an LP32 architecture such as i686 which could
conceivable provide 64-bit atomics, we might try to perform an atomic
operation on a potentially misaligned uint64_t value.
It has always been true that sem_t must have the same or higher
alignment as struct new_sem.
Could this be a problem on other architectures? (IA-32 is generally fine
with atomic operations on unaligned objects.)
That's why AArch64 ILP32 changes sem_t to use long long.
But shouldn't this work out of the box, i.e., with the generic sem_t,
you get something that is usable whether __HAVE_64B_ATOMICS is defined
And it doesn't quite answer my question.