I'm seeing new FAILs with -D_GLIBCXX_USE_CXX11_ABI=0 /home/test/src/gcc/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc:247: void test03(): Assertion '__gnu_test::counter::get()._M_increments == in crements + 1' failed. FAIL: 23_containers/unordered_set/96088.cc -std=gnu++17 execution test
/home/test/src/gcc/libstdc++-v3/testsuite/23_containers/unordered_map/96088.cc:240: void test03(): Assertion '__gnu_test::counter::count() == origin + incre ments' failed. FAIL: 23_containers/unordered_map/96088.cc -std=gnu++17 execution test On Tue, 22 Oct 2024 at 18:28, François Dumont <frs.dum...@gmail.com> wrote: > > Hi > > libstdc++: Always instantiate key_type to compute hash code [PR115285] > > Even if it is possible to compute a hash code from the inserted > arguments > we need to instantiate the key_type to guaranty hash code consistency. > > Preserve the lazy instantiation of the mapped_type in the context of > associative containers. > > libstdc++-v3/ChangeLog: > > PR libstdc++/115285 > * include/bits/hashtable.h (_S_forward_key<_Kt>): Always > return a temporary > key_type instance. > * testsuite/23_containers/unordered_map/96088.cc: Adapt to > additional instanciation. > Also check that mapped_type is not instantiated when there > is no insertion. > * testsuite/23_containers/unordered_multimap/96088.cc: > Adapt to additional > instanciation. > * testsuite/23_containers/unordered_multiset/96088.cc: > Likewise. > * testsuite/23_containers/unordered_set/96088.cc: Likewise. > * testsuite/23_containers/unordered_set/pr115285.cc: New > test case. > > > Tested under Linux x64, > > ok to commit ? > > François
