default C++ operator new's alignment

[Michael Clark]

it’s amazing how complicated we make things due to limitations in the underlying platform. if malloc were a macro defined to be aligned_alloc(_CRT_MINALIGN, size), with the alignment forwarded in an attribute, then the compiler could know. ideally, it would be composed that way.

if you want to replace a common symbol with a macro, you rename the symbol with a weak alias and use the alternate name in the macro. alas, this wouldn’t work cross-platform. but this is important for vector ABIs. I experienced a lot of segfaulting when porting code from platforms where MINALIGN is 16 instead of 8, so a macro would be useful. on a new platform, the CRT and libc could do this sanely. MINALIGN should be part of the CRT, as it relates to vector support function requirements, which are lower-level than the allocator in libc.

bumping minalign to 64 on a platform with 512-bit vectors is not the right fix. I don’t know why it isn’t 8 on 64-bit platforms. it possibly is on some.

> On 27 Oct 2026, at 7:50 PM, Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
> 
> On Tue, Oct 27, 2026 at 6:28 AM Andrea Pinski via Gcc <gcc@gcc.gnu.org> wrote:
>> 
>>> On Sun, Oct 11, 2026 at 7:56 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Sun, 11 Oct 2026, 03:22 Andrea Pinski via Gcc, <gcc@gcc.gnu.org> wrote:
>>>> 
>>>> What can we assume about the alignment about the default operator new
>>>> (the one without alignment supplied)?  Is it the same as malloc or
>>>> something different?
>>> 
>>> 
>>> It's aligned to __DEFAULT_NEW_ALIGNMENT__ (or however that's spelled).
>> 
>> Which internally to GCC is defined as aligned_new_threshold .
>> 
>> And that gets defined as:
>>  if (aligned_new_threshold == -1)
>>    aligned_new_threshold = (cxx_dialect >= cxx17) ? 1 : 0;
>>  if (aligned_new_threshold == 1)
>>    aligned_new_threshold = malloc_alignment () / BITS_PER_UNIT;
>> 
>> malloc_alignment () is defined as:
>> ```
>>  return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT);
>> ```
>> With the following comment:
>> ```
>> /* Return the alignment we expect malloc to guarantee.  This should just be
>>   MALLOC_ABI_ALIGNMENT, but that macro defaults to only BITS_PER_WORD for some
>>   reason, so don't let the threshold be smaller than max_align_t_align.  */
>> ```
>> 
>> So if I read this correctly, `operator new` for C++17 can assume
>> MALLOC_ABI_ALIGNMENT (like malloc) but anything before there is no
>> assumption can be made on the alignment.
>> Now the question is how should we represent this in the middle-end?
> 
> If the easy way doesn't work we can always add an attribute specifying
> alignment of a returned pointer.  Probably best to extend alloc_size
> though it's one-or-two arg form doesn't allow easy extension, so
> alloc_size_with_alignment maybe and have alignment specified first.
> That's because for size < max_align_t_align () the alignment can be smaller,
> so we do need to know a size.  Alternatively the FE could emit a
> __builtin_assume_aligned call wrapping the allocation.  Note the
> assume_aligned function attribute is less useful because of the size
> issue unless we specify combination with alloc_size will reduce alignment.
> 
>> Or would assuming MALLOC_ABI_ALIGNMENT be fine for C++98/11/14 too?
>> 
>> One thing is for overaligned operator new, we should be able to get
>> the alignment if it is constant.  Let me at least try to get that
>> working.
>> 
>> Thanks,
>> Andrea
>> 
>> 
>>> 
>>> 
>>>> The reason why I am asking is right now a __builtin_assume_aligned is
>>>> not removed while with malloc it is. (https://gcc.gnu.org/PR127674).
>>>> Plus I assume we are losing some optimizations with respect to the
>>>> vectorizer we might peel for alignment in some cases where we don't
>>>> have to even try.
>>>> 
>>>> Thanks,
>>>> Andrea