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 > <[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.
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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
