On Tue, Oct 27, 2026 at 6:28 AM Andrea Pinski via Gcc <[email protected]> wrote: > > 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?
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
