[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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.