From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27756 invoked by alias); 31 Mar 2015 15:13:49 -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 27734 invoked by uid 89); 31 Mar 2015 15:13:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 31 Mar 2015 15:13:47 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id A2C2491773; Tue, 31 Mar 2015 15:13:46 +0000 (UTC) Received: from anchor.twiddle.net (vpn-239-72.phx2.redhat.com [10.3.239.72]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2VFDjss001516; Tue, 31 Mar 2015 11:13:45 -0400 Message-ID: <551AB9A8.9000905@redhat.com> Date: Tue, 31 Mar 2015 15:13:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jonathan Wakely CC: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Andrew MacLeod Subject: Re: [libstdc++/65033] Give alignment info to libatomic References: <54DD19B7.6060401@redhat.com> <20150218121512.GI3360@redhat.com> <20150325162244.GF9755@redhat.com> <5513003D.3040107@redhat.com> <20150325184913.GH9755@redhat.com> <551306C1.6060702@redhat.com> <20150326132147.GL9755@redhat.com> <20150331134136.GS9755@redhat.com> <551AB523.5040203@redhat.com> <20150331150329.GT9755@redhat.com> In-Reply-To: <20150331150329.GT9755@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01673.txt.bz2 On 03/31/2015 08:03 AM, Jonathan Wakely wrote: > On 31/03/15 07:54 -0700, Richard Henderson wrote: >> On 03/31/2015 06:41 AM, Jonathan Wakely wrote: >>> This is the best I've come up with, does anyone have any better ideas >>> than the #else branch to hardcode alignment of 16-byte types to 16? >> >> If there's no 16 byte type, are we convinced this matters? I mean, there isn't >> a 16-byte atomic instruction for 32-bit x86 (or any other 32-bit cpu of which I >> am aware). So we're forced to use a locking path anyway. > > The C front end gives struct S { char s[16]; } 16 byte alignment... Um, I'm pretty sure it doesn't. struct S { char s[16]; }; int x = __alignof(struct S); .type x, @object .size x, 4 x: .long 1 What you're interpreting as alignment for that struct is probably optional *additional* alignment from LOCAL_ALIGNMENT or LOCAL_DECL_ALIGNMENT or something. > And it matters most for the integral types, not arbitrary structs. > >> And if we do want the alignment, do we stop pretending with all the sizeof's >> and alignof's and just use power-of-two size alignment for all of them, e.g. >> >> min_align = ((size & (size - 1)) || size > 16 ? 0 : size) > > Yeah, I wondered about that too. Joseph indicated there are targets > where C gives alignof(_Atomic X) != sizeof(X), which is why the target > hook exists, but maybe we can just not worry about those targets for > now. Those targets have alignof < sizeof. So in a way we'd probably be doing them a favor. I know for instance that CRIS is in this category, where most data is all byte aligned, but atomics must be naturally aligned. And, as you note, just so long as we do the same thing for _Atomic once we get that merged. r~