This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __HAVE_64B_ATOMICS and alignment

On 11/26/2016 09:52 PM, Andreas Schwab wrote:
On Nov 26 2016, Florian Weimer <> 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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]