https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #11 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- OK, I see. Although the PHI itself is not directly modified, a new PHI is introduced in the same block. During this process we may alter the incoming control flow to the block (introducing a new block along an incoming edge), which causes all the other PHIs in the block to be modified. Thus we cannot rely on a PHI in the candidate table maintaining its address throughout the pass. This imposes a requirement that we do not use the stmt_cand_map to look up a PHI candidate from a current PHI address, but always use the original PHI address that was cached away to perform the lookup. I believe it is possible to satisfy this by always using the stmt_cand_map->get (phi) call instead of calling base_cand_from_table. I'll work on a test patch.
