[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

2017-01-26 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 --- Comment #6 from Daryl Haresign --- I guess you don't want _M_copy_assign to be public, either.

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

2017-01-26 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 --- Comment #7 from Daryl Haresign --- I would also be inclined to reverse your Guard: have it take 'this', have an 'activate' method which swaps in the new values, have a 'deactivate' method which releases the memory, and have its destructor

[Bug libstdc++/79254] New: basic_string::operator= isn't exception safe

2017-01-26 Thread gcc-bugzilla at daryl dot haresign.com
: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at daryl dot haresign.com Target Milestone: --- Assigning one string to another, where they have non-equal propagate-on-copy-assignment allocators, does a `_M_destroy()`, followed by an `assign

[Bug c++/84222] New: [[deprecated]] class complains about internal class usage

2018-02-05 Thread gcc-bugzilla at daryl dot haresign.com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at daryl dot haresign.com Target Milestone: --- If I mark a class with the [[deprecated]] annotation, it complains when the class uses its own name in the implementation: class

[Bug c++/84222] [[deprecated]] class complains about internal class usage

2018-02-05 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222 --- Comment #1 from Daryl Haresign --- Additionally, any external use of a static method of a deprecated class should probably (but does not currently) emit a warning (Clang emits a warning). class [[deprecated]] C { public: void fn() {}

[Bug c++/84222] [[deprecated]] class complains about internal class usage

2018-02-05 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84222 --- Comment #2 from Daryl Haresign --- See also bug 79817.

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

2019-10-20 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #8 from Daryl Haresign --- (In reply to Jonathan Wakely from comment #5) > C11 6.2.8 says "Valid alignments > include only those values returned by an _Alignof expression for fundamental > types, plus an additional

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

2019-10-17 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #3 from Daryl Haresign --- $ g++-9 -E -dM test.cc | grep ALIGNED #define _GLIBCXX_HAVE_ALIGNED_ALLOC 1

[Bug c++/92143] New: std::pmr::polymorphic_allocator throws bad_alloc on macOS

2019-10-17 Thread gcc-bugzilla at daryl dot haresign.com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at daryl dot haresign.com Target Milestone: --- The following code throws a std::bad_alloc on macOS (seen via GCC 9.2 installed with Homebrew, on macOS Catalina 10.15): #include

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

2019-10-17 Thread gcc-bugzilla at daryl dot haresign.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92143 --- Comment #4 from Daryl Haresign --- As for conformance, the latest C draft says: The aligned_alloc function allocates space for an object whose alignment is specified by alignment, whose size is specified by size, and whose value is