From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4980 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 3/3] stddef: Define max_align_t Date: Mon, 28 Apr 2014 10:14:20 -0400 Message-ID: <20140428141420.GW26358@brightrain.aerifal.cx> References: <1398649434-23560-1-git-send-email-raj.khem@gmail.com> <1398649434-23560-3-git-send-email-raj.khem@gmail.com> <20140428020328.GV26358@brightrain.aerifal.cx> <20140428101156.GF12324@port70.net> <1398687764.7944.50.camel@eris.loria.fr> <20140428132645.GH12324@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1398694483 25725 80.91.229.3 (28 Apr 2014 14:14:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2014 14:14:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4984-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 28 16:14:36 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WemKI-0004S9-2q for gllmg-musl@plane.gmane.org; Mon, 28 Apr 2014 16:14:34 +0200 Original-Received: (qmail 9751 invoked by uid 550); 28 Apr 2014 14:14:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9740 invoked from network); 28 Apr 2014 14:14:32 -0000 Content-Disposition: inline In-Reply-To: <20140428132645.GH12324@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:4980 Archived-At: On Mon, Apr 28, 2014 at 03:26:45PM +0200, Szabolcs Nagy wrote: > * Jens Gustedt [2014-04-28 14:22:44 +0200]: > > Am Montag, den 28.04.2014, 12:11 +0200 schrieb Szabolcs Nagy: > > > i think i386 abi is non-conforming to the c11 alignment requirements now: > > > long long has 8 byte alignment, but in a struct/union it has only 4 > > > (this is why the attrs are needed above) > > > > > > long long x; // _Alignof(x) == 8 > > > struct {long long x;} y; // _Alignof(y.x) == 4 > > > > I don't think that it is non-conforming > > > > _Alignof of a type only tells you on what alignments the programmer > > may place objects of the corresponding type (if he deals with this > > manually) and gives no guarantee what the implementation itself choses > > under all circumstances > > > > this holds especially if a type has "extended alignment", I think > > the standard says > > "An object type imposes an alignment requirement on every object of that > type: stricter alignment can be requested using the _Alignas keyword." > > "The _Alignof operator yields the alignment requirement of its operand type." > > to me this means that all long long objects should have the same > alignment requirement and _Alignof should return this consistently > (unless _Alignas imposes further stricter alignment requirements, > but it never gets weaker) This is correct. On i386, _Alignof must both always be 4 for both long long and long double, regardless of where the operand (if it's an object rather than a type) exists. If gcc is behaving differently, this is a very bad bug in GCC that needs to be fixed on their side; I won't try to work around it. Rich