[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 --- > 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 "worst case O(n)", but

[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 --- Created attachment 30672 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30672&action=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 --- 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 changed: What|Removed |Added Attachment #30672|0 |1 is obsolete|

[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 --- > 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 there is an obscure issue, though. I

[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 --- 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 my problem by changing my

[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 changed: What|Removed |Added CC||temporal at gmail dot com --- Comment #5

[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 --- > 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 throwing destructors altoge

[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_tri