This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Benoit Jacob from comment #3)
> I'd be interested in an explanation of why the default STL allocator can't
> just honor the alignment of the value_type ?

[allocator.members] "It is implementation-defined whether over-aligned types
are supported" so we don't really have to. "the storage is obtained by calling
::operator new(std::size_t)" so we can't use posix_memalign (providing a
separate allocator that does could be a good idea though). We could, when the
type is over-aligned, do the usual trick of requesting too much memory so we
have enough margin to find a suitably aligned region inside, and write a marker
before so we remember where the real allocation started. That might be what was
tried in PR55727 (I didn't check), the maintainers might be ok with this if
someone posts a patch.

But calling new T would still be broken. It seems better in the long term to
add the aligned versions of operator new and make both new and std::allocator
use those (in the standard). Note that there would be ABI issues switching from
the trick in the previous paragraph to this.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]