On Tue, Sep 6, 2016 at 5:03 PM, Joseph Myers <jos...@codesourcery.com> wrote: > On Tue, 6 Sep 2016, Jason Merrill wrote: > >> On Tue, Sep 6, 2016 at 11:16 AM, Joseph Myers <jos...@codesourcery.com> >> wrote: >> > GCC is supposed to support all mallocs that produce results aligned to at >> > least MALLOC_ABI_ALIGNMENT (which may be smaller than the alignment of >> > max_align_t). >> >> I've just been running into problems with MALLOC_ABI_ALIGNMENT being >> smaller than max_align_t, which doesn't make sense to me; the C11 >> passage Florian quoted says that malloc needs to support all >> fundamental alignments, i.e. max_align_t. > > The point is that GCC supports being used in nonconforming implementations > as well as in conforming ones, and in nonconforming contexts people may > e.g. interpose malloc with a version that yields sufficient alignment for > common cases but may not use 16-byte alignment, or may not align small > objects as much as larger ones (whereas ISO C requires all alignments, > even 1-byte ones, be aligned as much as max_align_t).
MALLOC_ABI_ALIGNMENT is documented as "Alignment, in bits, a C conformant malloc implementation has to provide," which doesn't sound like it's intended to allow for non-conforming implementations. And doesn't a smaller default lead to lost optimization opportunities in the typical case? The reason I care is that C++17 aligned new (wg21.link/p0035) specifies that for types that require more alignment than the usual operator new provides, the new-expression instead calls an operator new with an explicit alignment parameter. MALLOC_ABI_ALIGNMENT sounded like exactly what I was looking for, but then I noticed that 'new long double' was going to the aligned new operator, which breaks older code that replaces operator new (without, of course, replacing the aligned variant). Jason