<div dir="ltr">On Fri, Oct 18, 2013 at 3:58 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Fri, Oct 18, 2013 at 03:22:23PM -0700, Arthur O'Dwyer wrote:<br>

> On Fri, Oct 18, 2013 at 3:01 PM, Joerg Sonnenberger<br>
> <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
> > On Fri, Oct 18, 2013 at 10:22:41AM -0700, David Majnemer wrote:<br>
> >><br>
> >> This implementation of max_align_t disagrees with gcc<br>
> [...]<br>
> >> gcc's alignof(max_align_t): 8<br>
> >> clang's alignof(max_align_t): 4<br>
> ><br>
> > Well, what is it supposed to do in the face of SSE2 registers? For all<br>
> > basic types, the IA32 ABI mandates at most 32bit alignment. With the<br>
> > compiler extensions it can certainly be at least 128bit.<br>
><br>
> The Standard seems pretty clear on the subject:<br>
> alignof(std::max_align_t) should be the largest "fundamental<br>
> alignment" supported by the implementation. It's<br>
> implementation-defined whether "overaligned types" (such as Altivec<br>
> 'vector' types, perhaps) exist, but certainly the invariant must be<br>
> maintained that alignof(std::max_align_t) >= alignof(long long).<br>
><br>
> It's also implied (7.6.2) that alignof(std::max_align_t) is the<br>
> largest value that can be reliably passed to alignas() in absolutely<br>
> any context. If Clang can't reliably align things to 8-byte<br>
> boundaries, then choosing alignof(max_align_t)==4 might actually be<br>
> defensible.<br>
><br>
> On a modern x86 compiler, I would expect alignof(max_align_t) to be at<br>
> least 16, since users will reasonably assume that if an address is<br>
> aligned to a max_align_t boundary, then it's safe to store any object<br>
> type there.<br>
<br>
</div></div>The danger of that assumption is that it can trigger stack-realignment<br>
on systems that still use the SYSV ABI. Those will by default only align<br>
to 32bit. I don't know whether any system still in use gives less than<br>
128bit alignment for malloc() return values.</blockquote><div><br></div><div>32-bit Windows CRT malloc() is specified to return 64-bit alignment.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 Frankly, this seems to be<br>
ill-defined...<br></blockquote><div><br></div><div>The C1X standard says:</div><div>"The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated)."<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Joerg<br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>