[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 #22 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #21)
> On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> > 
> > --- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
> > I think the anaylsis in comment 5 and onward needs to be redone since it was
> > using rangers debug output to see something wrong,  but the pass isn't even
> > using ranger.. It is using EVRP as we determined in comments 14 and 15.. 
> > 
> > So I do not know where this stands, I don't think ranger is even involved?
> 
> The ranger API is, which gives the caller the possibility to pass in
> a "context" stmt.  But with EVRP you can only ever query the "actual"
> context (the BB the domwalk currently is processing), since global
> ranges are adjusted.  If you ever ask for a different context you
> will get wrong answers.
> 
> So maybe the ranger API needs to be adjusted to ICE whenever the context
> is not the current one in case EVRP is active (not sure if it even knows
> about the EVRP domwalk).
> 
> Or using the ranger APIs should be forbidden when the EVRP domwalk is
> active (or the EVRP domwalk needs to be instructed to not adjust
> global ranges - IIRC we had a switch for that somewhere).

The EVRP implementation of range_of_expr() might be able to verify that the
context is correct at the time of the call and trap. I'll have a look. 

I'm not convinced that is whats at play here tho. Unless new code was added to
the pass to use ranger and it's API without actually converting it to ranger?