From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6076 invoked by alias); 21 Nov 2013 14:43:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6063 invoked by uid 89); 21 Nov 2013 14:43:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Nov 2013 14:43:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rALEhOOm032397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Nov 2013 09:43:24 -0500 Received: from [10.10.53.236] (vpn-53-236.rdu2.redhat.com [10.10.53.236]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rALEhMat020518; Thu, 21 Nov 2013 09:43:23 -0500 Message-ID: <528E1C0A.7020907@redhat.com> Date: Thu, 21 Nov 2013 18:03:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Hans-Peter Nilsson , "Joseph S. Myers" CC: gcc-patches@gcc.gnu.org Subject: Re: Implement C11 _Atomic References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg02727.txt.bz2 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? > > To wit, 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. > >> 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? 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. 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. > 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? > 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. 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 (MODE)); SET_ATOMIC_TYPE_NODE (atomicQI_type_node, QImode, unsigned_intQI_type_node); <...> 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. Andrew