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 <[email protected]> wrote: > > 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
