https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97379
--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Aldy Hernandez <al...@gcc.gnu.org>: https://gcc.gnu.org/g:739526a19deaeac19c2429cc7567052834d3098e commit r11-3852-g739526a19deaeac19c2429cc7567052834d3098e Author: Aldy Hernandez <al...@redhat.com> Date: Tue Oct 13 04:40:20 2020 -0400 Do not save hash slots across calls to hash_table::get_or_insert. There's a read of a freed block while accessing the default_slot in calc_switch_ranges. default_slot->intersect (def_range); It seems the default_slot got swiped from under us, and the valgrind dump indicates the free came from the get_or_insert in the same function: irange *&slot = m_edge_table->get_or_insert (e, &existed); So it looks like the get_or_insert is actually freeing the value of the previously allocated default_slot. Looking down the chain from get_or_insert, we see it calls hash_table<>::expand, which actually does a free while doing a resize of sorts: if (!m_ggc) Allocator <value_type> ::data_free (oentries); else ggc_free (oentries); This patch avoids keeping a pointer to the default_slot across multiple calls to get_or_insert in the loop. gcc/ChangeLog: PR tree-optimization/97379 * gimple-range-edge.cc (outgoing_range::calc_switch_ranges): Do not save hash slot across calls to hash_table<>::get_or_insert.
