On Mon, 13 Oct 2025 at 11:28, Tomasz Kaminski <[email protected]> wrote:
> > > On Mon, Oct 13, 2025 at 12:22 PM Jonathan Wakely <[email protected]> > wrote: > >> >> >> On Mon, 13 Oct 2025 at 10:08, Tomasz Kaminski <[email protected]> >> wrote: >> >>> >>> >>> On Sat, Oct 11, 2025 at 3:33 PM Jonathan Wakely <[email protected]> >>> wrote: >>> >>>> We need to ensure that the memory allocated for a path::_List::_Impl is >>>> at least 4-byte aligned, so that we can use the two least significant >>>> bits to store a _Type value. Use __STDCPP_DEFAULT_NEW_ALIGNMENT__ to >>>> detect whether we need to use aligned new/delete to get memory with >>>> unused low bits. >>>> >>>> Allocation and deallocation of path::_List::_Impl objects is refactored >>>> into a new _Impl::create function so that the memory allocation is done >>>> in one place and can ensure the required alignment. >>>> >>> If I understand correctly we do not have a target >>> where __STDCPP_DEFAULT_NEW_ALIGNMENT__ is >>> smaller than 4. If so, wouldn't static_assert be better instead of >>> effectively dead code? >>> >> >> >> I think it's dead code in all targets supported by upstream GCC. It's >> possible there are out-of-tree ports for other microprocessors >> where __STDCPP_DEFAULT_NEW_ALIGNMENT__ < 4, and if we use a static_assert >> they would need to do additional work in their port. But we can add a >> comment to the static_assert, and maybe deal with that problem later if it >> ever happens (YAGNI). >> > As an alternative, I would be fine if we only had one code path, and > always used an aligned version of the new. > And we just add if (align <= __STDCPP_DEFAULT_NEW_ALIGNMENT__) return > ::operator new(sz) in the align_val_t > operator new implementation. > > I considered that, but thought it would be an ABI change for targets where memory from aligned-new allocates additional memory to store a cookie (see libsupc++/new_opa.cc). But thinking about it more carefully, as long as the aligned-new and aligned-delete are globally consistent in the program, it would be OK. There might be a problem for a target that needs the cookie (e.g. Windows) where you can have different new/delete operators in each DLL (e.g. Windows).
