https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126814
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Drea Pinski from comment #6) > Anyways the real issue is the call to gimple_stmt_nonnegative_p; it should > be removed and reimplemented in gimple-range-op.cc's maybe_builtin_call. (a > bug which I am about to file shows why). Yes, the fundamental issue is that fold_using_range::range_of_call is provided a range _query via a fur_source parameter, which in this case is a global_range_query... specifically because the cache does not want to spawn any new queries. When gimple_stmt_nonnegative_p is called, it does eventually invoke get_range_query(cfun) and that causes issues. We ran into this earlier too where the interface to gimple_range_fold is provided a query which isnt the current one, but the the current one ends up being used down the chain because not everyone uses the fur_source mechanism for alternate queries... Implementing this call in in gimple_range_op might work, but im starting to wonder if maybe the fold_using_range interface ought to stash the current query for the duration of the call and replace it with the specified one. This would resolve any future issues due to use of the current query in unexpected places. I will experiment.
