This is the mail archive of the
mailing list for the GCC project.
Re: Atomic operations and unaligned memory
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jonathan Wakely <redi at gcc dot gnu dot org>, GCC <gcc at gcc dot gnu dot org>
- Date: Thu, 26 Mar 2015 16:13:27 -0400
- Subject: Re: Atomic operations and unaligned memory
- Authentication-results: sourceware.org; auth=none
- References: <551465C8 dot 3050409 at redhat dot com>
On 03/26/2015 04:02 PM, Jason Merrill wrote:
That was the original grand plan... I vaguely recall a slow backing
away from that as not being worth the trouble and previously unforeseen
The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says,
typedef char B3;
_Atomic B3 obj2;
An object will be promoted up to the next lock-free size in order to
enable lock free operations, as long as it isn't already a documented
lock free size. So obj2 will be promoted to a 4 byte object with
whatever alignment is required in order to enable lock-free operations.
But the implementation doesn't follow this. First, the above is
rejected due to applying _Atomic to an array type. If we wrap the
array in a struct, the resulting atomic object still has size 3 and
Did the design change, or is this a bug?
I would hazard a guess that its now a design change.