> What would you suggest this function to do, based on your comments? I'm not familiar enough with VRP to answer at that level, but at a higher level, what I'd advocate is that the *generator* of information would track things both ways, assuming wrapping and non-wrapping semantics (of course, if -fwrapv or -fno-wrapv was specified, it would only do that one). Then the *user* of the information would decide which one to use by applying heuristics based both on the likelihood that the programmer would be relying on wrapping and the importance from an optimization standpoint of not doing so.
So, for example, when making decisions involving loop optimizations, it would assume that bivs and givs don't overflow. But it if saw a comparison against a result that might overflow, it would assume the more conservative choice on the grounds that it's more likely that the test was intended to do something than to always be true or false. Here is where you also have a chance of issuing a warning. In the former of these cases, however, I don't think it would make sense to issue one since it'd almost always be a false positive and in the latter there is nothing to warn about since the conservative choice is being made. But in some "middle of the road" cases, assuming undefined overflow and warning might be the most appropriate: indeed, the ability to issue the warning could be a justification towards making the less conservative choice.