On 25 July 2012 21:29, François Dumont wrote:
(_Hashtable::rehash): Likewise. Set _M_prev_resize to 0 to avoid
the hashtable to be shrinking on next insertion.
Not to be shrinking just shrinking, but nevermind.
Attached patch applied on 4.7 branch.
Tested under Linux x86_64.
I will fix this small english issue in trunk ChangeLog.
François
On 07/26/2012 11:11 AM, Jonathan Wakely wrote:
On 25 July 2012 21:29, François Dumont wrote:
(_Hashtable::rehash): Likewise. Set _M_prev_resize to 0 to
On 07/25/2012 04:55 PM, Jonathan Wakely wrote:
Yes, I think so, it's a regression from 4.6.
Thanks for dealing with it so quickly.
Thanks indeed.
However, looks like we have another issue, unrelated to reserve, pure
performance not correctness, with the sheer number of rehashes when the
map
(CC gcc-patches)
On 25 July 2012 10:26, François Dumont wrote:
Hi
Here is a patch proposal for PR 54075. I also took the occasion to fix
something that has been delay so far which is usage of std::max to get the
number of buckets to use. The problem of using std::max when using the hash
Attached patch applied to trunk. I am building 4.7 branch to also apply
the patch to this branch.
2012-07-25 François Dumont fdum...@gcc.gnu.org
PR libstdc++/54075
* include/bits/hashtable.h
(_Hashtable::_Hashtable(_InputIterator, _InputIterator,
size_type,
