<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 16, 2018, at 4:50 AM, Stephan Bergmann via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">On 16/02/17 13:34, Stephan Bergmann via cfe-dev wrote:</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">On 02/16/2017 02:34 AM, Richard Smith wrote:<br class=""><blockquote type="cite" class="">On 13 February 2017 at 06:55, Stephan Bergmann <<a href="mailto:sbergman@redhat.com" class="">sbergman@redhat.com</a><br class=""><<a href="mailto:sbergman@redhat.com" class="">mailto:sbergman@redhat.com</a>>> wrote:<br class=""> <span class="Apple-converted-space"> </span>* At least with the wording from P0035R4, it is unclear to me what<br class=""> <span class="Apple-converted-space"> </span>the alignment requirements in<br class=""><br class=""> <span class="Apple-converted-space"> </span>struct S { char a[25]; };<br class=""> <span class="Apple-converted-space"> </span>S * func() { return new S(); }<br class=""><br class=""><br class=""> <span class="Apple-converted-space"> </span>are. When compiled at -O for x86_64-unknown-linux-gnu, Clang trunk<br class=""> <span class="Apple-converted-space"> </span>apparently assumes that the pointer returned from operator new is<br class=""> <span class="Apple-converted-space"> </span>16-byte aligned (writing to it with movaps). But the requirements<br class=""> <span class="Apple-converted-space"> </span>for that operator new in [new.delete.single] merely states that it<br class=""> <span class="Apple-converted-space"> </span>"allocates storage suitably aligned to represent any object of that<br class=""> <span class="Apple-converted-space"> </span>size", and I don't think there is a type of size 25 with a stricter<br class=""> <span class="Apple-converted-space"> </span>alignment requirement than 1 for that target.<br class=""><br class=""><br class="">Yes, you're right that this is at best unclear and at worst says that<br class="">our assumption is not valid for allocations that are not a multiple of<br class="">the allocator alignment. This is the subject of C++ core issue 2207<br class="">(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2207" class="">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2207</a>, but<br class="">there's no information on the public version of the issues list yet);<br class="">there generally seemed to be consensus in committee discussion that<br class="">global non-array non-aligned operator new should provide sufficient<br class="">storage for any object with a fundamental alignment that fits in the<br class="">storage, not just for fundamental alignments that divide the allocated size.<br class=""><br class="">For instance, we want to guarantee that this sort of thing works:<br class=""><br class="">S *p = func();<br class="">static_assert(sizeof(long double) <= 25);<br class="">new (p->a) long double; // ok, 'a' is suitably aligned for 'long double'<br class=""><br class="">Is this assumption causing problems in practice?<br class=""></blockquote>Don't know of any. I stumbled across all this when seeing that the Firebird DBMS has a global operator new replacement that generally does merely 8-byte alignment on x86-64. But I haven't come across an issue related to this fits--vs.--matches-exactly size assumption.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Revisiting this now, I think I /do/ see a problem in practice after all with Clang making too aggressive assumptions about the aligned-ness of storage returned by "plain" global operator new, at least with the Firebird 3.0 that is bundled by LibreOffice:</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Firebird replaces that "plain" global operator new, which gets called with an argument of 24, and recent Clang (on both Linux and macOS x86-64) uses movaps (requiring 16-byte aligned memory) on the result. (And the result happens to be only 8-byte aligned, causing a SEGV.)</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">According to the x86-64 SysV ABI, a struct with a 16-byte alignment requirement would need to have a size that is a multiple of 16 bytes, so Firebird's operator new replacement should be OK returning merely 8-byte aligned storage for a request of 24 bytes.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div class=""><br class=""></div>I don't think this is a valid line of reasoning. Users can call `operator new` themselves, and they are not required to call it with the `sizeof` some specific type. It's a pretty common idiom to allocate a header (usually pointer-aligned) + a trailing array (aligned to whatever the element type requires), and in fact that's an ABI-mandated pattern in C++ (albeit with operator new[] — and since it only happens for types with destructors it's very unlikely to trigger on a byte-aligned element type).</div><div class=""><br class=""></div><div class="">John.</div></div></body></html>