From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7930 invoked by alias); 23 Jan 2017 14:00:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7636 invoked by uid 89); 23 Jan 2017 14:00:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Jan 2017 14:00:20 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 669EAAD9E; Mon, 23 Jan 2017 14:00:08 +0000 (UTC) Date: Mon, 23 Jan 2017 14:00:00 -0000 From: Michael Matz To: Richard Henderson cc: Torvald Riegel , Bin Fan , "gcc@gcc.gnu.org" , Jakub Jelinek Subject: Re: GCC libatomic ABI specification draft In-Reply-To: <280f53fc-31d1-d1d6-35f5-154672e5c463@redhat.com> Message-ID: References: <8764e547-1dd2-3ebd-2723-6568b4b54092@oracle.com> <1470412312.14544.4.camel@localhost.localdomain> <4a182edd-41a8-4ad9-444a-bf0af567ae98@oracle.com> <8317ec9d-41ad-d806-9144-eac2984cdd38@oracle.com> <1484672405.5606.420.camel@redhat.com> <2cc60e20-8b70-1be3-e052-b3c0f5b0750c@redhat.com> <280f53fc-31d1-d1d6-35f5-154672e5c463@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00197.txt.bz2 Hi, On Fri, 20 Jan 2017, Richard Henderson wrote: > > 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. Ah well, in that case I lost context as well ;) Ciao, Michael.