__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