[Bug libstdc++/65122] std::vector doesn't honor element alignment

["jacob.benoit.1 at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122

--- Comment #11 from Benoit Jacob <jacob.benoit.1 at gmail dot com> ---
(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.

> 
> 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.