[PATCH] Define max_align_t in C++11 and C11 mode

[Joerg Sonnenberger]

On Fri, Oct 18, 2013 at 03:22:23PM -0700, Arthur O'Dwyer wrote:
> On Fri, Oct 18, 2013 at 3:01 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Fri, Oct 18, 2013 at 10:22:41AM -0700, David Majnemer wrote:
> >>
> >> This implementation of max_align_t disagrees with gcc
> [...]
> >> gcc's alignof(max_align_t): 8
> >> clang's alignof(max_align_t): 4
> >
> > Well, what is it supposed to do in the face of SSE2 registers? For all
> > basic types, the IA32 ABI mandates at most 32bit alignment. With the
> > compiler extensions it can certainly be at least 128bit.
> 
> The Standard seems pretty clear on the subject:
> alignof(std::max_align_t) should be the largest "fundamental
> alignment" supported by the implementation. It's
> implementation-defined whether "overaligned types" (such as Altivec
> 'vector' types, perhaps) exist, but certainly the invariant must be
> maintained that alignof(std::max_align_t) >= alignof(long long).
> 
> It's also implied (7.6.2) that alignof(std::max_align_t) is the
> largest value that can be reliably passed to alignas() in absolutely
> any context. If Clang can't reliably align things to 8-byte
> boundaries, then choosing alignof(max_align_t)==4 might actually be
> defensible.
> 
> On a modern x86 compiler, I would expect alignof(max_align_t) to be at
> least 16, since users will reasonably assume that if an address is
> aligned to a max_align_t boundary, then it's safe to store any object
> type there.

The danger of that assumption is that it can trigger stack-realignment
on systems that still use the SYSV ABI. Those will by default only align
to 32bit. I don't know whether any system still in use gives less than
128bit alignment for malloc() return values. Frankly, this seems to be
ill-defined...

Joerg