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
