This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: __HAVE_64B_ATOMICS and alignment
- From: Andreas Schwab <schwab at linux-m68k dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 26 Nov 2016 21:52:43 +0100
- Subject: Re: __HAVE_64B_ATOMICS and alignment
- Authentication-results: sourceware.org; auth=none
- References: <430bd9b7-a6fd-7247-7b60-965bd0486bbf@redhat.com>
On Nov 26 2016, Florian Weimer <fweimer@redhat.com> wrote:
> I'm describing the background for this question. The opaque sem_t
> definition looks like this:
>
> typedef union
> {
> char __size[__SIZEOF_SEM_T];
> long int __align;
> } sem_t;
>
> But the __HAVE_64B_ATOMICS definition of the non-opaque version looks like
> this:
>
> struct new_sem
> {
> uint64_t data;
> int private;
> int pad;
> };
>
> 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.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."