This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
- From: "glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 19 Feb 2015 20:59:25 +0000
- Subject: [Bug libstdc++/65122] std::vector doesn't honor element alignment
- Auto-submitted: auto-generated
- References: <bug-65122-4 at http dot gcc dot gnu dot org/bugzilla/>
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.