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

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 19 Jan 2022, amacleod at redhat dot com wrote:

> 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?

Well, I don't see where EVRP ever had range_of_expr (), so that's clearly
a ranger API and thus if the pass is using that and passing in a context
that is asking for trouble.

But from a quick look we're only passing down the stmt we're currently
analyzing and ultimatively process via strlen_pass::before_dom_children.

Unless pointer-query.cc somehow changes 'stmt' or does caching based
on only SSA names, not including the 'stmt' context they were produced.
Indeed the cache is populated with put_ref which doesn't have any
'stmt' context but an SSA name only.  Martin?  It seems some
queries computing the cached size use the 'stmt' context of the _use_
but the cache is for definition points?