* Re: Is changing __STDCPP_DEFAULT_NEW_ALIGNMENT__ an ABI break
2022-03-20 15:38 Is changing __STDCPP_DEFAULT_NEW_ALIGNMENT__ an ABI break Doods Pav
@ 2022-03-21 11:15 ` Jonathan Wakely
0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Wakely @ 2022-03-21 11:15 UTC (permalink / raw)
To: Doods Pav; +Cc: gcc-help
On Sun, 20 Mar 2022 at 15:39, Doods Pav via Gcc-help
<gcc-help@gcc.gnu.org> 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.
^ permalink raw reply [flat|nested] 2+ messages in thread