[Bug c++/59426] New: __has_trivial_{copy/assign} behavior differs from documentation

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: temporal at gmail dot com Consider this struct with deleted copy/assignment: struct S { S(const S) = delete; S operator=(const S) = delete; }; GCC's __has_trivial_{copy,assign

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799 --- Comment #7 from Kenton Varda temporal at gmail dot com --- It's now 2013 so the sensible thing to do is not return by value if your destructor can throw. That actually sounds like a pretty difficult rule to follow, unless you either ban

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799 Kenton Varda temporal at gmail dot com changed: What|Removed |Added CC||temporal at gmail

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153 --- Comment #6 from Kenton Varda temporal at gmail dot com --- Yep, I realize that erase_after would need to be added to the standard. I was just speculating that it may be something the standard committee should consider. I've long since solved

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153 --- Comment #4 from Kenton Varda temporal at gmail dot com --- This report entry made me wonder why iterators could not just be pointing to the node just before the one containing the pointed to value. That's a neat idea. I think

[Bug c++/58192] New: G++ emits incorrect code when passing enum classes as function parameters

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: temporal at gmail dot com Demonstration attached. It repros with g++ 4.8.1 (tested on Ubuntu and Cygwin). I think I saw similar problems with g++ 4.7.3, but this particular test

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 --- Comment #1 from Kenton Varda temporal at gmail dot com --- Created attachment 30672 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30672action=edit Demonstration of enum class passing bug

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 --- Comment #2 from Kenton Varda temporal at gmail dot com --- Note: Both the Ubuntu and Cygwin systems were x86_64. I don't know if the problem occurs in 32-bit mode.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 Kenton Varda temporal at gmail dot com changed: What|Removed |Added Attachment #30672|0 |1

[Bug libstdc++/58153] New: unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: temporal at gmail dot com It appears that if an unordered_multimap has k entries with the same key, then erase(iter) for any of those entries is O(k

[Bug libstdc++/58153] unordered_multimap::erase(iterator) is not constant-time when many entries have the same key

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58153 --- Comment #2 from Kenton Varda temporal at gmail dot com --- The standard says average case O(1), worst case O(a.size()), so if every element in the container has the same key then it's O(n). I'm not sure that follows. Yes, the standard says