https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126110
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 65041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=65041&action=edit potential patch This issue is caused by the way Ranger tracks dependencies using timestamps. A cached value is considered stale when one of its inputs has a newer timestamp. Several factors combine to trigger the failure. 1. The first expression: _1 = insn_13(D)->code; registers an inferred use of the default definition `insn_13`, refining its range from `VARYING` to `[1, +INF]` in blocks dominated by this statement. In on-demand mode, a query for `insn_13` scans its immediate uses and registers this inference. During a dominator walk, Ranger instead registers the inference as it encounters the statement for efficiency. It then relies on dependency timestamps to correct any values that were calculated earlier, such as across backedges. 2. Before the dominator walk, the PHI analyzer visits: # set_6 = PHI <insn_13(D)(2), elt_15(D)(3)> At this point the inference for `insn_13` has not yet been registered, so its range is `VARYING`. The PHI result `set_6` is therefore also cached as `VARYING`. Later, during the dominator walk, the inferred range `[1, +INF]` is registered for `insn_13` in block 2. However, because `insn_13` is a default definition, no new calculated value is written to the cache and therefore no timestamp is updated. Dependency tracking therefore does not recognize that the corresponding PHI input is stale, and the cached `VARYING` value for `set_6` continues to be used. The underlying problem is that dependency tracking is based on stored values. A use-derived refinement of a default definition does not involve a normal calculation or cache write, so there is no timestamp change to invalidate dependent values. The attached patch makes the inferred-range manager call the current `range_query` object's `update_range` mechanism whenever a new inferred range is registered. For an ordinary SSA name, this marks its cached value stale so that it will be recalculated. A default definition has no defining statement and therefore cannot be recalculated. Ranger now handles this case by assigning the default definition a new timestamp directly. This causes SSA names that depend on it to become stale, causing them to be recalculated using the newly inferred range. Currently running it through testing.
