https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 54738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54738&action=edit Patch to fix the issue Ah, sorry I missed that. OK, I traced it through. The problem turns out to be in the dom_resolve code. when we are trying to pick up a value via dominators, we walk the dominator chain looking for outgoing edges which change the value and/or existing values. As we find these values, will fill the on-entry cache so that future queries will be faster. When we encounter a dominator node that has multiple incoming edges, as BB 33 does, we separately ask for a "quick" read-only fill and accumulate each incoming edges values. this allows us to pick up things where ranges are adjusted on edges from non-dominator block ie bb2: if (foo) if (a < 10) goto A: else goto B; else if (a >= 10) goto C: else goto A: <more code> goto D: A: Block A's dominator is bb2. It has 2 predecessors however, and on each of those incoming edges, a has a range of [0, 10]. So by querying the outgoing range of a on each predecessor we come up with [0,10] for a range of A, which would not be possible simply by examining the dominator itself. This query is done in a read-only mode so we dont go polluting the cache with a bunch of things we may not need. Anyway, it all works swimmingly. usually. What happened in this case is BB 33 has 2 predecessors. BB 28 and BB 32. The edge from BB28 correctly picked up the range of ~[0,0], but the query for BB32 went wrong. BB32 is a back edge, and the query leads back to BB 33, and in read only mode, we do not deal with these multiple incoming edges.. (and it avoids an infinite loop).. so that query bails, and we end up with VARYING. that is what was generating the confusing output: CACHE: BB 32 DOM query for c_24, found [irange] unsigned char * VARYING at BB28 CACHE: Range for DOM returns : [irange] unsigned char * VARYING CACHE: Range for DOM returns : [irange] unsigned char * VARYING When we are doing this inferior DOM query in read-only like this like this, we do not need to incorporate anything from a back edge. Its intended to be pulling a value from dominators, and there is no additional information on that edge. Any values from that edge can only be subsets of what the other incoming edges have, and with the results being unioned... its pointless. I have not yet managed to produce a reduced testcase.
