[cfe-dev] operator new alignment assumptions

[Stephan Bergmann via cfe-dev]

On 02/16/2017 02:34 AM, Richard Smith wrote:
> On 13 February 2017 at 06:55, Stephan Bergmann <sbergman at redhat.com
> <mailto:sbergman at redhat.com>> wrote:
>     *  At least with the wording from P0035R4, it is unclear to me what
>     the alignment requirements in
>
>         struct S { char a[25]; };
>         S * func() { return new S(); }
>
>
>     are.  When compiled at -O for x86_64-unknown-linux-gnu, Clang trunk
>     apparently assumes that the pointer returned from operator new is
>     16-byte aligned (writing to it with movaps).  But the requirements
>     for that operator new in [new.delete.single] merely states that it
>     "allocates storage suitably aligned to represent any object of that
>     size", and I don't think there is a type of size 25 with a stricter
>     alignment requirement than 1 for that target.
>
>
> Yes, you're right that this is at best unclear and at worst says that
> our assumption is not valid for allocations that are not a multiple of
> the allocator alignment. This is the subject of C++ core issue 2207
> (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2207, but
> there's no information on the public version of the issues list yet);
> there generally seemed to be consensus in committee discussion that
> global non-array non-aligned operator new should provide sufficient
> storage for any object with a fundamental alignment that fits in the
> storage, not just for fundamental alignments that divide the allocated size.
>
> For instance, we want to guarantee that this sort of thing works:
>
> S *p = func();
> static_assert(sizeof(long double) <= 25);
> new (p->a) long double; // ok, 'a' is suitably aligned for 'long double'
>
> Is this assumption causing problems in practice?

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.

And thanks for the pointer to issue 2207.  Hadn't spotted that one before.