https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #11 from Jeffrey A. Law <law at redhat dot com> --- We have two different SSA_NAMEs where their SSA_NAME_INFO is the same pointer. Thus modification range info by way of set_range_info changes the underlying range on both SSA_NAMEs. From a debugging session: (gdb) p cfun->gimple_df->ssa_names.m_vecdata[1045].ssa_name.info.range_info $33 = (range_info_def *) 0x7fffefa4a420 (gdb) p cfun->gimple_df->ssa_names.m_vecdata[938].ssa_name.info.range_info $34 = (range_info_def *) 0x7fffefa4a420 So to follow how we get to that state. First ccp_finalize calls set_nonzero_bits on SSA_NAME 938. That allocates a hunk of memory and initializes it with the right information. Then ccp_finalize calls set_nonzero_bits on SSA_NAME 1045. That allocates another hunk of memory and initializes it appropriately. The actual recorded ranges are different -- they differ in nonzero_bits. So far, so good. No problems. Then FRE comes along and decides the two SSA_NAMEs are equal and executes this code: /* Use that from the dominator. */ SSA_NAME_RANGE_INFO (to) = SSA_NAME_RANGE_INFO (from); SSA_NAME_ANTI_RANGE_P (to) = SSA_NAME_ANTI_RANGE_P (from); TO is SSA_NAME 1045, FROM is SSA_NAME 938. At that point we have two distinct SSA_NAMEs with a shared SSA_NAME_RANGE_INFO pointer. EVRP then comes along and calls set_range_info on SSA_NAME 1045, which has the side effect of changing the range info on SSA_NAME 938. This changes the nonzero bits associated with SSA_NAME 938 (which ultimately results in incorrect code starting in a later CCP pass). Shortly thereafter we release SSA_NAME 1045 because its LHS is going to be fully propagated away. And it makes perfect sense why last week'd change to not set range info on statements marked for removal can cause this bug to go latent. We avoid the call to set_range_info on SSA_NAME 1045 and thus don't clobber the nonzero bits for SSA_NAME 938. FWIW, knowing that I can diff the .ccp2 dumps to look for evidence of this issue gave me some hope I could reduce the testcase further without worrying about still being able to execute the test. Alas that didn't make any significant difference -- a few things were removed, but not enough to significantly simplify the test. BTW, I don't expect to be online much over the next few days... Good luck...