Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Dec 2019 12:45:30 -0500
From: Rich Felker <>
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.
> 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:
> 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

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.


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.