https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Aldy Hernandez from comment #4) > (In reply to Jakub Jelinek from comment #3) > > r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d > > > > Note, I've just committed the PR107879 fix, but that one is for the reverse > > operations. > > And, we have still unresolved the PR107608 which on the other side could > > very well be related or the cause of this. > > BTW, Aldy, is there a way to disable all range related optimizations through > > some command line option? In the past, -fno-tree-vrp would do the trick, > > but now that the ranger is used in lots of passes, I don't know what else to > > use. > > Not really, as ranger clients are spread around various passes. > > I think you could return false from irange::supports_p() and > frange::supports_p() and that would block everyone using ranger. It would > certainly stop range_of_expr and range_of_edge, which are the main > workhorses. yes, we could add some form of disable.. wmaybe add something like --param=ranger-disable=[all|float|int|gori] all - disables all ranger queries (ie, they return false) float - removes support for folating point int - removes support for integrals gori - removes support for op1/op2 backwiding I think we could do something like that if it was useful? It would apply across the board to any and all uses of ranger in all passes We could also add a ranger dbgcnt counter too,which would we could trigger in one or more of the routines...?