__HAVE_64B_ATOMICS and alignment
Florian Weimer
fweimer@redhat.com
Sun Nov 27 11:33:00 GMT 2016
On 11/26/2016 09:52 PM, Andreas Schwab wrote:
> 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.
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
or not?
And it doesn't quite answer my question.
Florian
More information about the Libc-alpha
mailing list