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 17:40:50 +0100
From: Florian Weimer <>
To: Rich Felker <>
Subject: Re: max_align_t mess on i386

* 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

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

I think this is what GCC uses internally in its optimizers.  I don't
think it's exposed directly.

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.