This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
__HAVE_64B_ATOMICS and alignment
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 26 Nov 2016 19:49:06 +0100
- Subject: __HAVE_64B_ATOMICS and alignment
- Authentication-results: sourceware.org; auth=none
I'm trying to figure out what __HAVE_64B_ATOMICS means. Does it imply
that atomics must be available for unaligned 64-bit objects (such as a
pair of longs), or only for 8-byte aligned values of type uint64_t?
What happens if the architecture only mandates 4-byte alignment for
uint64_t?
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.
Could this be a problem on other architectures? (IA-32 is generally
fine with atomic operations on unaligned objects.)
Thanks,
Florian