[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121

--- Comment #30 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Sebor from comment #29)
> From memory: At use1 the cache is empty so go and find its definition and
> record the offset at that point, with the pointer addition as the context. 
> And at use2 we look up the same offset.  So use1 won't reflect the constant
> offset.  That could be both good (if the code is unreachable) and bad (if it
> is and the use is invalid.
> 
> If it did work the way you're concerned I'd expect to see a lot of
> mysterious false positives.  The cache has been in use since GCC 11 and I
> don't recall coming across any puzzling problems.  But we have seen an
> uptick in false positives in GCC 12 after we switched over to Ranger so let
> me double check it really does work the way I say it does.

  ptr_1 = &a + _2;
  if (_2 == 0)
    use1 (ptr_1);
  use2 (ptr_1);

If you call ranger and ask for the _2 range and provide the context as stmt
"use1 (ptr_1)",  It will certainly return [0, 0].  ... because you are asking
for the range of _2 at that point.

If you then cache that that would be wrong.  So if you are "visiting" the
definition for the first time, you would want to provide the DEF_STMT as the
context... You want to know the range of _2 is at the DEF point of ptr_1, not
the use point later on.    Then you will get whatever _2 is at the def point
which is probably varying at this point. 

just to be aware..