https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #4) > I suppose I was expecting that that after EVRP (and before VRP1) > get_range_info() would either succeed and return a range representing a > subrange of the the variable's type or fail and return VR_VARYING. But that's what it did! It succeeded in finding an anti-range that describes a subrange of the variable's type (sizetype). > If instead the first one or two times the tree-object-size pass ran > it could somehow determine that a) the range it got from get_range_info() > wasn't as good as it could be, and b) that it will run again and will get > another chance to refine the result, it could avoid using the suboptimal > results and ultimately return the correct answer. Looks like you want to enable your new transformation only in the last object-size pass? Otherwise, there is always a chance the range might shrink before the next pass (though there might also be a possibility for a wider range, if we commonize several calls to __bos).