[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #10 from Bill Seurer --- It works for me, too, now. Thanks!
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #9 from Dmitry G. Dyachenko --- (In reply to Patrick Palka from comment #8) > Thanks for the reports. This should now hopefully be fixed with r11-522. r11-526 PASS for me. Thanks
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Thanks for the reports. This should now hopefully be fixed with r11-522.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:610ae2dbbf98a291782cb05c0fb31e056193e5e2 commit r11-522-g610ae2dbbf98a291782cb05c0fb31e056193e5e2 Author: Patrick Palka Date: Wed May 20 09:15:48 2020 -0400 c++: spec_hasher and TYPENAME_TYPE resolution [PR95223] After enabling sanitization of the specialization tables, we are triggering one of the hash table sanity checks in the below testcase. The reason is that when looking up the specialization j in the type_specializations table, the sanity check finds that the existing entry j::m> compares equal to j but hashes differently. The discrepancy is due to structural_comptypes looking through TYPENAME_TYPEs (via resolve_typename_type), something which iterative_hash_template_arg doesn't do. So the TYPENAME_TYPE n::m is considered equal to int, but the hashes of these two template arguments are different. It seems wrong for the result of a specialization table lookup to depend on the current scope, so this patch makes structural_comptypes avoid calling resolve_typename_type when comparing_specializations. In order for the below testcase to deterministically trigger the sanitization error without this patch, we also need to fix the location of the call to hash_table::verify within hash_table::find_with_hash. gcc/ChangeLog: PR c++/95223 * hash-table.h (hash_table::find_with_hash): Move up the call to hash_table::verify. gcc/cp/ChangeLog: PR c++/95223 * typeck.c (structural_comptypes): Don't perform context-dependent resolution of TYPENAME_TYPEs when comparing_specializations. gcc/testsuite/ChangeLog: PR c++/95223 * g++.dg/template/typename23.C: New test.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #6 from Iain Sandoe --- r11-511 + this patch builds a stage1 debug compiler OK for me (issue reported on irc).
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #5 from Patrick Palka --- Candidate patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546106.html
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 --- Comment #4 from Bill Seurer --- It was definitely r11-477. I see this causing an ICE when building gcc albeit only on power 9.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Jonathan Wakely changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #3 from Jonathan Wakely --- *** Bug 95225 has been marked as a duplicate of this bug. ***
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Last reconfirmed||2020-05-19 Keywords||ice-checking Ever confirmed|0 |1 --- Comment #2 from Patrick Palka --- Confirmed. Very likely caused by my r11-477.
[Bug c++/95223] [11 regression] hash table checking failed: equal operator returns true for a pair of values with a different hash value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95223 Jonathan Wakely changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Jonathan Wakely --- This is a compiler crash, so it's not a libstdc++ bug.
