From owner-cvs-src@FreeBSD.ORG Sun Nov 19 09:16:05 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B20F16A403; Sun, 19 Nov 2006 09:16:05 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47C0C43D4C; Sun, 19 Nov 2006 09:15:56 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kAJ9Fuox092757; Sun, 19 Nov 2006 12:15:56 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kAJ9Fkjc092754; Sun, 19 Nov 2006 12:15:46 +0300 (MSK) (envelope-from yar) Date: Sun, 19 Nov 2006 12:15:46 +0300 From: Yar Tikhiy To: "Daniel O'Connor" Message-ID: <20061119091545.GE80527@comp.chem.msu.su> References: <20061117201432.X11101@delplex.bde.org> <20061118202125.GD80527@comp.chem.msu.su> <1F361437-69AC-4823-8FF8-506EA450ED2F@mac.com> <200611191842.17673.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611191842.17673.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.9i Cc: src-committers@freebsd.org, Bruce Evans , jkoshy@freebsd.org, Marcel Moolenaar , cvs-all@freebsd.org, phk@phk.freebsd.dk, cvs-src@freebsd.org, "M. Warner Losh" Subject: Re: cvs commit: src/include ar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2006 09:16:05 -0000 On Sun, Nov 19, 2006 at 06:42:07PM +1030, Daniel O'Connor wrote: > On Sunday 19 November 2006 07:35, Marcel Moolenaar wrote: > > Also, since this discussion is the result of ARM aligning structures > > on 4-byte boundaries, I think that the use of __packed to compensate > > for excessive alignment is just plain wrong. We have __aligned(x) to > > inform the compiler about what the alignment of an object should be > > and that's the tool we should use to tell the compiler on ARM that > > we in fact want 1-byte alignment. take for example, the following > > structure: > > Just a quick point.. > __aligned__ only specified a minimum packing requirement - there is no way to > specify a maximum (I believe) > > If the underlying problem IS too large an alignment then you're screwed if you > want a reasonably portable solution.. Perhaps __packed__ convinces the > compiler to reduce alignment. Quoting the GCC docs: aligned (alignment) This attribute specifies a minimum alignment for the variable or structure field, measured in bytes. ... The aligned attribute can only increase the alignment; but you can decrease it by specifying packed as well. This can be read as follows: __packed and __aligned(FOO) together can specify an exact alignment FOO less than the default one. -- Yar