https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #25 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 14 12:03:47 2016
New Revision: 241158
URL: https://gcc.gnu.org/viewcvs?rev=241158=gcc=rev
Log:
PR65122 extended alignment support in allocators
PR libstdc++/65122
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
Bug 65122 depends on bug 77742, which changed state.
Bug 77742 Summary: Warning about placement new for over-aligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77742
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #23 from Jonathan Wakely ---
I think it's supposed to be cover everything, but I'm not sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #22 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #20)
> In C++17 std::allocator no longer says "It is implementation-defined whether
> over-aligned types are supported" and is no longer required to call operator
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #21 from Jonathan Wakely ---
Created attachment 39686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39686=edit
Make new_allocator support types with new-extended alignment
This works, but currently produces a warning due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #19 from Marc Glisse ---
(In reply to Andrew Pinski from comment #17)
> I think this is fixed for GCC 7 with -std=c++17 support.
No, it isn't. new T[10] will give suitably aligned memory, but not
std::allocator. Only the core part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #18 from Benoit Jacob ---
(In reply to Andrew Pinski from comment #17)
> I think this is fixed for GCC 7 with -std=c++17 support.
Thanks for the update, that's great news!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #17 from Andrew Pinski ---
I think this is fixed for GCC 7 with -std=c++17 support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #16
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #13 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
(In reply to Richard Biener from comment #12)
(In reply to Benoit Jacob from comment #11)
(In reply to Richard Biener from comment #10)
But ::operator new(std::size_t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Benoit Jacob from comment #13)
(In reply to Richard Biener from comment #12)
(In reply to Benoit Jacob from comment #11)
(In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
Oh, and I wonder if there is an aligned realloc (though C++ doesn't define
sth like realloc and thus std::vector can't optimize the copy when
reallocating?!). But for a C program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #3 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
I'd be interested in an explanation of why the default STL allocator can't just
honor the alignment of the value_type ? (The document linked in comment 2
seemed to assume that
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 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #5 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
So while the standard says that over-aligned types dont have to be supported,
it also says in 3.11/9 in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #6 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
(In reply to Marc Glisse from comment #4)
the storage is obtained by
calling ::operator new(std::size_t) so we can't use posix_memalign
Ouch. That's very unfortunate. I see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
IMHO the only sensible solution is in this direction:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm
I hope Clark is still working on this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #8 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
If there is a defect in the standard, isn't it in the part that forces the
compiler to not use the useful type information that it has, that is, the
above-quoted the storage is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #9 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
s/compiler/standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #7 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Benoit Jacob from comment #6)
I would still be interested in how you understand 3.11/9
I consider it a defect in the standard, so it needs fixing, not
understanding...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Benoit Jacob from comment #6)
(In reply to Marc Glisse from comment #4)
the storage is obtained by
calling ::operator new(std::size_t) so we can't use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #1 from Benoit Jacob jacob.benoit.1 at gmail dot com ---
Homologous libc++ bug report: http://llvm.org/bugs/show_bug.cgi?id=22634
26 matches
Mail list logo
