https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #1)
> Started with r13-6945-g429a7a88438cc80e
I've run into this before.
_54 = _22
is processed, and we cache _22 as a dependency fo _54.
then we do some propagation and rewrite this statement as
_54 = 3
When we look at _54 later, it still shows the cached dependency as _22, but
there is no longer a _22 in the IL.
We are trapping because may_recompute_p is expecting the dependency to be up to
date. The fix is to check if it is in the FREE_LIST or not as well.
Patch in testing.
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 5f4313b27dd..2a575c006fc 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -1314,7 +1314,7 @@ gori_compute::may_recompute_p (tree name, basic_block bb,
int depth)
tree dep2 = depend2 (name);
// If the first dependency is not set, there is no recomputation.
- if (!dep1)
+ if (!dep1 || SSA_NAME_IN_FREE_LIST (dep1))
return false;
