[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tv601awd.fsf@mid.deneb.enyo.de>
Date: Mon, 16 Dec 2019 17:40:50 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
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.
@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
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
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.
