This is the mail archive of the
mailing list for the GCC project.
Re: GCC libatomic ABI specification draft
- From: Richard Henderson <rth at redhat dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Torvald Riegel <triegel at redhat dot com>, Bin Fan <bin dot x dot fan at oracle dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 20 Jan 2017 09:17:46 -0800
- Subject: Re: GCC libatomic ABI specification draft
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <alpine.LSU.email@example.com>
On 01/20/2017 05:41 AM, Michael Matz wrote:
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
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.