[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #40 from frs.dumont at gmail dot com 2012-11-07 22:02:56 UTC --- Here is the patch to fix the redundant rehash/reserve issue. 2012-11-07 François Dumont PR libstdc++/54075 * include/bits/hashtable.h (_Hashtable<>::rehash): Reset hash policy state if no rehash. * testsuite/23_containers/unordered_set/modifiers/reserve.cc (test02): New. I had prepared and tested it in 4.7 branch but I can apply the same on trunk. Ok to commit ? If so, where ? François On 11/06/2012 10:33 PM, paolo.carlini at oracle dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 > > --- Comment #39 from Paolo Carlini > 2012-11-06 21:33:57 UTC --- > Ok thanks. I guess depending on the complexity of the fixes we can apply some > only to mainline first and reconsider the 4_7 branch later. Please do your > best > to work on both issues: we just entered Stage 3 thus no new features from now > on, we are all concentrated on bug fixes until the release. >
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #46 from frs.dumont at gmail dot com 2012-11-08 20:21:15 UTC --- Attached patch applied to trunk and 4.7 branch. 2012-11-08 François Dumont PR libstdc++/54075 * include/bits/hashtable.h (_Hashtable<>::rehash): Reset hash policy state if no rehash. * testsuite/23_containers/unordered_set/modifiers/reserve.cc (test02): New. François On 11/08/2012 01:58 AM, Jonathan Wakely wrote: > On 7 November 2012 22:02, François Dumont wrote: >> Ok to commit ? If so, where ? > That patch is OK for trunk and 4.7, thanks. >
[Bug libstdc++/54075] [4.7.1] unordered_map insert still slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #47 from frs.dumont at gmail dot com 2012-11-08 21:19:05 UTC --- On 11/08/2012 03:25 AM, Paolo Carlini wrote: > On 11/08/2012 02:56 AM, Paolo Carlini wrote: >> On the other hand, the old-old code for rehash didn't use >> _M_growth_factor in these computations, it just literally enforced >> the post-conditions of the Standard. Are we sure we aren't so to >> speak rehashing too much? For example, when the load factor is very >> low and doesn't count, it looks like a current rehash(n) accomplishes >> the same of an old rehash(n * 2)?!? Something seems wrong, can you >> double check that? In any case the comments before _M_next_bkt would >> need fixing. > ... in other terms, I really think that the only uses of > _S_growth_factor should return to be inside _M_need_rehash, because > that's the function called by the inserts, when the container must > automatically grow the number of buckets. Elsewhere, like the > constructors, rehash, should not need to know about _S_growth_factor. > > Paolo. > I haven't yet considered the following emails but based on those good remarks I have done the attached patch. Surprisingly it seems to have a good impact on performance even if before it testsuite/performance/23_containers/insert/unordered_set.cc was showing that new implementation was better. I have also starting to adapt tests so that it's possible to check unordered performance with std or std::tr1 implementations. Can I generalize it to other tests ? If so, is it a good approach ? François
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 --- Comment #9 from frs.dumont at gmail dot com --- To be honest before that report I thought that preserving abi was just a matter of preserving memory layout of types. I had no idea that member methods mattered ! Lesson learned. On 11/09/2023 13:52, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 > > --- Comment #8 from Jonathan Wakely --- > (In reply to François Dumont from comment #1) >> It seems to be a limited issue as you need a non-optimized build. > That's not a safe assumption. Inlining decisions can change across builds and > across architectures, and it's not safe to assume the affected functions will > always be inlined, e.g. in the presence of explicit instantiation definitions. > >> The only >> impacted member is the _M_next() which is a simple static_cast, I'm very >> surprised that it's not always inlined even if non-optimized. > No functions are inlined for non-optimized builds, unless forced with > always_inline. >
[Bug libstdc++/90276] PSTL tests fail in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 --- Comment #9 from frs.dumont at gmail dot com --- Here is the reason of the 20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc FAIL. Maybe it fixes some other tests too, I need to run all of them. libstdc++: Do not forward arguments several times [PR90276] Forwarding several times the same arguments results in UB. It is detected by the _GLIBCXX_DEBUG mode as an attempt to use a singular iterator which has been moved. libstdc++-v3/ChangeLog PR libstdc++/90276 * testsuite/util/pstl/test_utils.h: Remove std::forward<> calls when done several times on the same arguments. Ok to commit ? François On 31/01/2024 14:11, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276 > > Jonathan Wakely changed: > > What|Removed |Added > > See Also||https://github.com/llvm/llv > ||m-project/issues/80136 >
[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
--- Comment #15 from frs.dumont at gmail dot com ---
On 05/11/2024 18:18, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285
>
> --- Comment #14 from Jonathan Wakely ---
> We're assuming that an iterator's reference type can be converted to the
> key_type. This doesn't compile on trunk:
>
> #include
>
> struct K {
>explicit K(int) noexcept { }
>bool operator==(const K&) const { return true; }
> };
>
> template<> struct std::hash {
>auto operator()(const K&) const { return 0ul; }
> };
>
> int i[1];
> std::unordered_set s(i, i+1);
>
>
> This fails for similar reasons:
>
> #include
>
> struct K {
>explicit K(int) noexcept { }
>bool operator==(const K&) const { return true; }
> };
It's surprising that we need to handle this use case. The user wants K
is to be explicitly built from int but then insert ints, weird. Are
other Standard library handling this ?
You know C++ Standard much better than I do though.
