This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: GCC libatomic ABI specification draft


On 01/20/2017 05:41 AM, Michael Matz wrote:
Hi,

On Wed, 18 Jan 2017, Richard Henderson wrote:

Section 3 Rationale, alternative 1: I'm wondering if the example is
correct.  For a 4-byte-aligned type of size 3, the implementation
cannot simply use 4-byte hardware-backed atomics because this will
inevitably touch the 4th byte I think, and the implementation can't
know whether this is padding or not.  Or do we expect that things like
packed structs are disallowed?

If we atomically store an unchanged value into the 4th byte, can we
tell?

You can't have a 4-aligned type of size 3.  Sizes must be multiples of
alignment (otherwise arrays don't work).  The type of a 3-sized field in
a packed struct that syntactically might be a 4-aligned type (e.g. by
using attributes on char-array types) is actually a different type having
an alignment of 1.  It's easier to simply regard all types inside packed
structs as 1-aligned (which is IMO what we try to do).

That is, the byte after a 4-aligned "3-sized" type is always padding.

[ I read Bin Fan's original email some months ago, but I don't have it handy now. Take faulty memory with a grain of salt. ]

I thought this was about libatomic being presented with an unaligned 3-byte structure that happens to sit within an aligned 4-byte word, and choosing to atomically operate on the 4-byte word instead of taking a lock on the side.


r~


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