From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15034 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: max_align_t mess on i386 Date: Mon, 16 Dec 2019 12:45:30 -0500 Message-ID: <20191216174530.GD1666@brightrain.aerifal.cx> References: <20191214151932.GW1666@brightrain.aerifal.cx> <20191215182242.GA1666@brightrain.aerifal.cx> <20191216155622.GC1666@brightrain.aerifal.cx> <87tv601awd.fsf@mid.deneb.enyo.de> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="176733"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-15050-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 16 18:45:45 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iguRF-000jmb-Fx for gllmg-musl@m.gmane.org; Mon, 16 Dec 2019 18:45:45 +0100 Original-Received: (qmail 9698 invoked by uid 550); 16 Dec 2019 17:45:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9677 invoked from network); 16 Dec 2019 17:45:42 -0000 Content-Disposition: inline In-Reply-To: <87tv601awd.fsf@mid.deneb.enyo.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:15034 Archived-At: On Mon, Dec 16, 2019 at 05:40:50PM +0100, Florian Weimer wrote: > * Rich Felker: > > > I wasn't aware of this gcc feature. Do you know if it's documented and > > what it's derived from? It seems to match what max_align_t is expected > > to be, including on i386 (16) and powerpc (16) and indeed it's only 4 > > on a few 32-bit archs and even 2 on m68k. > > @defmac BIGGEST_ALIGNMENT > Biggest alignment that any data type can require on this machine, in > bits. Note that this is not the biggest alignment that is supported, > just the biggest alignment that, when violated, may cause a fault. > @end defmac > > I don't think it does what you are after: > > $ gcc -mavx512f -dM -E - #define __BIGGEST_ALIGNMENT__ 64 Indeed. Thanks. > I suspect this is closer: > > @defmac MALLOC_ABI_ALIGNMENT > Alignment, in bits, a C conformant malloc implementation has to > provide. If not defined, the default value is @code{BITS_PER_WORD}. > @end defmac The latter looks buggy. It's clearly supposed to be in bits, not bytes, with some archs defining it as 64 or 128 and: gcc/defaults.h:#ifndef MALLOC_ABI_ALIGNMENT gcc/defaults.h:#define MALLOC_ABI_ALIGNMENT BITS_PER_WORD However arm has: gcc/config/arm/arm.h:#define MALLOC_ABI_ALIGNMENT BIGGEST_ALIGNMENT which is in bytes... > I think this is what GCC uses internally in its optimizers. I don't > think it's exposed directly. No problem; I don't think we want to derive it dynamically from something compiler-dependent. I was just looking for a way to check what GCC's expectations are and this seems reasonable. Rich