This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/51386] [4.7 Regression]: 23_containers/unordered_set/hash_policy/load_factor.cc execution timeout
- From: "paolo.carlini at oracle dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 02 Dec 2011 11:10:36 +0000
- Subject: [Bug libstdc++/51386] [4.7 Regression]: 23_containers/unordered_set/hash_policy/load_factor.cc execution timeout
- Auto-submitted: auto-generated
- References: <bug-51386-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51386
--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-02 11:10:36 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > Hans-Peter, can it be a memory issue? The recent changes imply that more memory
> > is used by these data structures, and that is largely unavoidable,
>
> Unavoidable, really?
**If** where only a memory issue would be unavoidable yes. This is a long,
long, discussion which took place in various LWG ISO Meetings, about the
performance of erase, which we can't summarize here. Unavoidably a C++11
conforming hashed container uses more memory that a legacy HP/SGI hash_map /
hash_set.
But I don't think is a memory issue, now.