[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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...?