https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Benoit Jacob from comment #11) > (In reply to Richard Biener from comment #10) > > But ::operator new(std::size_t) could always return memory aligned for the > > most over-aligned type? Thus our default new implementation could use > > posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)? > > The problem is there are lots of use cases for really high alignment: AVX > brings uses of 32-byte alignment, and cache lines are typically >= 64 byte > aligned. So alignas has to support at least 64 or 128 byte alignment to > support cache friendly code, and even without that, it would have to support > at least 32 byte alignment for AVX vectorized code. > > Making all allocations that large would lead to substantial allocator slop. > For example, jemalloc has a quantum of 8 or 16 byte depending on whether the > arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big > difference. Though does it really matter in practice? Tiny allocations would not suffer because of the MIN (align, size), so the worst-case is max-align + 1 allocations. Btw, you could as well try MIN (align, size & -size), thus assume that the allocation size is N * alignof (). > > > > If the user provides its own ::new then he is on its own, of course > > I agree that's how I would like things to be. Unfortunately, the spec quote > in comment 4, "the storage is obtained by calling ::operator > new(std::size_t)", goes in the opposite direction, by requiring allocators > to use the type-blind ::new , thereby losing useful type information such as > the type's alignment. That's why I think that this is the spec's weak spot > that might be questioned. but you're the expert, not me :) > > > (and > > doing that and using posix_memalign in it would be a workaround for this > > issue?!). > > That could be a good compromise for many applications, that either don't > care about minimizing memory usage, or don't do many tiny allocations. > Unfortunately, my context here is a library (Eigen), so we can't make this > decision for all our users.
