On 6/19/26 02:26, Richard Biener wrote:
On Thu, Jun 18, 2026 at 4:23 PM Andrew MacLeod <[email protected]> wrote:fold_using_range is provided a range_query object to work on. when all other options fails when trying to calculate a range, the gimple fold machinery can be invoked to see if a statement might fold to a constant. If this object is not the current_range_query (cfun) object, it can trigger an unexpected call into a different range query. This is causing problems in ranger_cache which is implemented as a range_query and expects to complete its query before another one is invoked. If the query's escape the cache, and go back to the current range query, this can cause a re-entrance to the cache we don't expect. This patch simply checks that the current query is th provided query before invoking gimple fold. This ensures we only get the expected behaviour. Bootstrapped on x86_64-pc-linux-gnu with no regressions. pushed.Thanks - but I suppose iff we fire of SCEV/niter paths or other tools that are now ranger enabled this can still happen. Maybe it would be better to have a range-query stack so we can do push_query (src.query ()); pop_query (); in toplevel entries and push/pop_query would manage cfun->query? I guess for efficiency the stack would need a { query, counter } as it will otherwise grow quickly given ranger invokes itself recursively?Andrew
Well, it can only happen when a non-ranger query is being invoked... if the pass uses enable_ranger and the current range query like they are suppose to, everything should be fine. It would be uncommon for there to be a second active range_query in use using the fold machinery other than rangers cache. Maybe a path ranger... but again this would prevent the fold machinery from engaging during a path ranger query.. which is probably a good thing. I wouldn't expect to see it in other places
if we do, we can figure out how to address it. I will keep it in mind. Andrew
