https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898
--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #8) > I agree that in many cases there isn't enough information to tell that a > range is final and can't be further improved. But there certainly are such > cases (the test case in comment #0 is an example of one) The function could get inlined and i become constant... > I think it should be possible to call set_range_info() on the result of the > __builtin_object_size, and perhaps even on the offset variable in (p += i) > since its value is constrained not only by the range of its type (before > VRP1) and by statements like the 'if (i < 0 || 1 < i) i = 0;' (after VRP1) > but also by the increment '(p += i)' which is only defined for i in [0, 3] > as determined by the tree-object-size pass before VRP1. Let me give that a > try. Careful with that last point. When we compute i+10 (in type int), we do not restrict the range of i to [INT_MIN, INT_MAX-10]. The reason is that this restriction is only valid starting from this statement, not from the definition of i. > It seems to me that there should many other opportunities to call > set_range_info() in GCC that could help improve the generated code (and the > ability to find bugs via warnings). I count just 9 calls to the function in > the whole code base. It makes sense that most range computation happens in VRP (which has a single set_range_info in a loop at the end). This pass duplicates variables to get some sort of "local" range, which allows for tighter estimates. If you replace 'i = 0' with 'return' in your first example, then i may generally be any int, but in the branch that contains __bos, it can only be in the range [0, 1], which is something you are only aware of during the VRP pass.
