https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #10 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- The stmt_cand_map is *not* losing its integrity. Instead, it appears that a phi statement changes its address at some point during the SLSR pass, even though it hasn't been modified (SFAICT). There are two candidates that have the same PHI statement as a phi-basis. For each of them we call phi_add_costs with parameter "phi" containing the same address. We look up the PHI statement in the candidate table as follows: slsr_cand_t phi_cand = base_cand_from_table (gimple_phi_result (phi)); The base_cand_from_table function (which is called from many places) looks up the PHI statement from the phi-result using SSA_NAME_DEF_STMT, which is then used to query the stmt_cand_map. The first time through, SSA_NAME_DEF_STMT returns the same address as the original parameter "phi," as expected. The second time, however, it returns a new address. Both the new and old address have mostly identical information, but the new address does not appear in the candidate table, so the stmt_cand_map returns 0 unexpectedly, leading to the crash. By "mostly identical," I mean that the two statements have a different SSA_NAME for the phi-result, but both SSA_NAMEs identify _1338 as the name in question. This is probably the source of the problem, but so far I don't see what would cause us to create this unnecessary SSA_NAME structure. A workaround that would probably fix this is to replace the above statement with: slsr_cand_t phi_cand = stmt_cand_map->get (phi); which would avoid rediscovering the "moved" phi statement. I probably want to do this anyway, but I want to first understand what caused the extra SSA_NAME and PHI statement to get created.
