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 rguent...@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?
