https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Andrew Macleod from comment #5) > what do you mean? when a statement is changed, it may generate a different > range than it did before, No, that would be a bug. If some IL changes need to extend existing range, then reset_flow_sensitive_info needs to be called for the SSA_NAME. > so we re-evaluate the statement to see if the > result is different. If it is, then we update it in the cache. > > All its doing is re-calculating and updating the cache values. > > It looks to me like the problem is the stmt is being added in a way that > leaves the IL in an illegal state, But unfortunately that is pretty much unavoidable in changes like this. So, I have lhs1 = some_stmt; and want to change it to lhs2 = some_stmt; lhs1 = (lhs_type) lhs2; (where lhs2 has a different type from lhs). The options to do that are either what the code does right now, i.e. first create lhs1 = (lhs_type) lhs2; stmt, add it after lhs1 = some_stmt; (including update_stmt), then gimple_set_lhs on the first stmt to lhs2, then update_stmt on the first stmt, but this is temporarily invalid IL, because two different stmts in the IL have the same lhs, or as changed in the patch gimple_set_lhs on the first stmt to lhs2 (but no update_stmt), create the second stmt, add it including update_stmt, then update_stmt on the first one; this is also invalid IL, the effects of update_stmt haven't been done until the second update_stmt; or gimple_set_lhs and update_stmt on the first one (but then lhs1 has no definition and we insert a stmt into the IL without the definition, so again temporarily invalid IL).
