[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
