On Fri, Oct 18, 2013 at 3:01 PM, Joerg Sonnenberger <[email protected]> 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. my $.02, –Arthur _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
