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?
