https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99259
--- Comment #3 from Benoit Jacob ---
Thanks for bringing up the topic of early-clobber. I had to look up some
explanation of that concept, but I found that and now I get what you're saying
- thanks!
https://stackoverflow.com/questions/15819794/wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99259
Benoit Jacob changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: jacob.benoit.1 at gmail dot com
Target Milestone: ---
compiler explorer link: https://godbolt.org/z/9oE5Ta
Note: Clang has the same bug: https://bugs.llvm.org
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 #13 from Benoit Jacob ---
(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) could always return memory a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #11 from Benoit Jacob ---
(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_mema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #9 from Benoit Jacob ---
s/compiler/standard library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #8 from Benoit Jacob ---
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 obtained by calling ::operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #6 from Benoit Jacob ---
(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. I would still be interested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #5 from Benoit Jacob ---
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:
> If a request for a specific ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #3 from Benoit Jacob ---
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 that goes without saying?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #1 from Benoit Jacob ---
Homologous libc++ bug report: http://llvm.org/bugs/show_bug.cgi?id=22634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900
Benoit Jacob changed:
What|Removed |Added
CC||jacob.benoit.1 at gmail dot com
onent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jacob.benoit.1 at gmail dot com
Created attachment 34807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34807&action=edit
testcase
Even in C++11 mode, even with the C++11 alignas keyword, element ali
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jacob.benoit.1 at gmail dot com
Created attachment 33497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33497&action=edit
testcase
Consider this testcas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
--- Comment #14 from Benoit Jacob 2011-11-07
21:57:18 UTC ---
\o/
You rock!
16 matches
Mail list logo
