|
Message-ID: <20191216174530.GD1666@brightrain.aerifal.cx> Date: Mon, 16 Dec 2019 12:45:30 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: max_align_t mess on i386 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 - </dev/null | grep -i align > #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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.