This is the mail archive of the
mailing list for the GCC project.
Re: Implement C11 _Atomic
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 21 Nov 2013 09:43:22 -0500
- Subject: Re: Implement C11 _Atomic
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311052316480 dot 30260 at digraph dot polyomino dot org dot uk> <alpine dot BSF dot 2 dot 02 dot 1311210545480 dot 43309 at arjuna dot pair dot com>
On 11/21/2013 06:05 AM, Hans-Peter Nilsson wrote:
On Tue, 5 Nov 2013, Joseph S. Myers wrote:
Thanks for doing this! However, without examples I have trouble
reading out the bits I need as a target maintainer, and I can't
read out the answers from the patch, so pardon a few questions.
Support for atomic types having bigger alignment than the
corresponding non-atomic types is limited: it includes the code to
increase the alignment of types whose size is exactly 1, 2, 4, 8 or 16
to that of the corresponding integer type [*], but not anything for
target-specific alignment increases.
Target-maintainer perspective here: do I read that correctly,
that by default adding _Atomic raises the alignment of that type
to the "natural" one, for all targets?
It sets up the default alignment for all atomic integral types to be
that of the natural alignment of their integer counterpart. ie
alignof(_Atomic short) = alignof (short)
For non-integral types, if sizeof (type) == sizeof (integral-type),
then it makes sure that alignof (type) is at least as large as alignof
(_Atomic integral-type), and overrides it if necessary, allowing the
lock-free routines to work the same for non-integral types.
Yes, I believe the override code is still on the branch. There is a
target hook which allows the alignment for an atomic type to be changed.
There's code for target-specific
alignment on the branch (and I intend to merge trunk back to the
branch once this patch is on trunk, so it's easy to tell what the
changes still left on the branch are), should any target maintainers
wish to have such alignment.
...is that part needed for alignment that is only
target-specific and other-than-natural? For example, 8-byte
aligment where required for atomic 4-byte types?
So, the cris port would be able to override the alignment of the
atomicHI_type_node and make it 4 bytes aligned, which would then cause
any variable declared as _Atomic short to automatically be 4 byte aligned.
If I understand correctly, yes, it would be needed there as well.... if
the compiler thinks alignof (int) is 1, then I believe it will set
alignof(_Atomic int) to 1 as well, and that's probably not good.
Or is that part also required for
anything-other-than-ordinary-C-type alignment for the target;
say, natural 4-byte alignment of 4-byte-types for targets where
alignment is otherwise "packed"; where only 1-byte alignment of
the basic type is ABI-mandated?
Basically, atomic_types are given their own type nodes in tree.c:
atomicQI_type_node = build_atomic_base (unsigned_intQI_type_node);
atomicHI_type_node = build_atomic_base (unsigned_intHI_type_node);
atomicSI_type_node = build_atomic_base (unsigned_intSI_type_node);
atomicDI_type_node = build_atomic_base (unsigned_intDI_type_node);
atomicTI_type_node = build_atomic_base (unsigned_intTI_type_node);
and on the branch that code instead looks something like:
#define SET_ATOMIC_TYPE_NODE(TYPE, MODE, DEFAULT) \
(TYPE) = build_atomic_base (DEFAULT, targetm.atomic_align_for_mode
SET_ATOMIC_TYPE_NODE (atomicQI_type_node, QImode,
which provides a target hook to override the default values and a target
can set them to whatever it deems necessary.
There was insufficient time to test and fully flush this out, so it
hasn't made it into mainline. Its only thanks to Josephs heroic efforts
we have C11 :-)
I don't think its a lot of code if you wanted to fool with it for your port.