On Sun, 20 Mar 2022 at 15:39, Doods Pav via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > > Is changing the value of the predefined macro > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` considered an ABI break? (in the same > way that modifying `alignof(std::max_align_t)` would be). It depends. If the OS's C library does not provide aligned_alloc or posix_memalign or memalign then it's an ABI break. If the C library doesn't provide one of those functions, then the operator new(size_t, align_val_t) function needs to do additional bookkeeping to be able to deallocate the aligned memory. The value of that macro determines whether a given object size uses operator new(size_t) or operator new(size_t, align_val_t), so if you change the value of the macro you change whether additional bookkeeping is needed for a given object size. If different parts of the program disagree, you could allocate memory using the aligned form and then try to deallocate it using the non-aligned operator delete(void*, size_t), which would have undefined behaviour. This is the case on Windows, as it only provides _aligned_malloc/_aligned_free, which are not compatible with malloc/free. It might also be the case on very old versions of newlib and other C libraries. Also, if your program replaces operator new(size_t) and/or operator new(size_t, align_val_t) and makes them incompatible, then changing the default new alignment is also an ABI break (because for the same reasons as above, different parts of the program will disagree on whether a given object size uses the overaligned new/delete or not). In the common case (the OS supports one of the libc aligned allocation functions, and you don't replace new/delete) it's not an ABI break. > I would assume that it is, but I saw this comment on a bug report ( > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691#c33) and I'm unsure if > the value of the macro was later changed in a patch, and if so, if that was > considered an ABI break. The macro wasn't changed.
