On Mon, 13 Oct 2025 at 11:45, Jonathan Wakely <[email protected]> wrote:
> > > 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). > Oh actually Windows provides _aligned_malloc an _aligned_free, so it doesn't need the cookie.
