From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4978 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 3/3] stddef: Define max_align_t Date: Mon, 28 Apr 2014 15:26:45 +0200 Message-ID: <20140428132645.GH12324@port70.net> 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> 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 1398691626 7881 80.91.229.3 (28 Apr 2014 13:27:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Apr 2014 13:27:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4982-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 28 15:26:59 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 1WelaE-0006Lh-Q7 for gllmg-musl@plane.gmane.org; Mon, 28 Apr 2014 15:26:58 +0200 Original-Received: (qmail 13470 invoked by uid 550); 28 Apr 2014 13:26:57 -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 13459 invoked from network); 28 Apr 2014 13:26:57 -0000 Content-Disposition: inline In-Reply-To: <1398687764.7944.50.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4978 Archived-At: * 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) in my example x and y.x are long long objects but have different alignment requirements there is no exception here for types with extended alignments or "alignment support contexts" > > i think the standard requires that all (addressable) long long objects > > should have the same alignment (or stricter) than _Alignof(x) (it seems that _Alignof is specified for objects with register storage class too, so even non-addressable long longs should have the same alignment requirement whatever that means) > > max_align_t is defined to be the "greatest alignment supported in all > > contexts", i don't know why it is not just > > This only concerns "fundamental alignments". Also, this sentence has > an implicit "minimum" operator that comes from the "in all contexts" > > if the alignment restriction is 8 in some context and 4 in others, the > result is 4 and not 8. > > Perhaps all of this can be made consistent on i386 by having > _Alignof(max_align_t) to be 4 and declare 8 byte and 16 byte aligned > types as having "extended alignment" > no, long long (or any scalar type) cannot be an "over-aligned" type "A type having an extended alignment requirement is an over-aligned type." "Every over-aligned type is, or contains, a structure or union type with a member to which an extended alignment has been applied." > I am not sure that I remember correctly, but it seems to me that i386 > allows for 4 byte alignment of all types, only that this results in > suboptimal code if long long has an alignment requirement of 4 byte then _Alignof should say so > > typedef char max_align_t __attribute__((aligned(__BIGGEST_ALIGNMENT__))); > > > > which gives 16 byte alignment on i386 gcc, i thought it was supported > > in all contexts > > I think this just not necessary and even counter productive. depends on what is the semantic meaning of max_align_t currently it means "guaranteed to be supported in all contexts" > > if gcc and clang went with the same definition we should follow, but > > this makes the type less meaningful > > By looking at the page that you linked to, my impression is that they > got it wrong. I think basically > > typedef union max_align_t max_align_t; > > union max_align_t { > long double a; > uintmax_t b; > void* c; > max_align_t* d; > }; > > should do the trick. All other alignments should be considered as > extended alignments. the implementation may support greater alignments