https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> --- 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. If the range returned by get_range_info() gets refined as other passes provide more insight into the data flow through the program (which makes perfect sense) then there ought to be a way for callers to hold off on using the suboptimal range if another one is coming than might be better. To translate it to the case I'm dealing with: the tree-object-size pass runs three times, the first time after EVRP but before VRP1, then again after VRP1, and finally after VRP2. If the first time it runs it calls get_range_info() to compute the result of (p += 1) and gets back [INT_MIN, INT_MAX] then it will set the minimum size of the object to which p points to 0 resulting in __builtin_object_size (p, 2) returning a subopptimal value. 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.
