On Sun, Oct 11, 2026 at 7:56 AM Jonathan Wakely <[email protected]> wrote:
>
>
>
> On Sun, 11 Oct 2026, 03:22 Andrea Pinski via Gcc, <[email protected]> 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?
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
