Jeffrey A Law wrote: > One possibility that isn't as drastic would be to add one to the > TYPE_MAX_VALUE of the inner type, then see if the result fits in > the outer type.
Yes, that's basically the idea that is implemented in chrec_convert. Because we're in a loop and we keep adding "one"s to the base, we have to know how many times we are going to add the step to the base. Thus there are three restrictions for a static analyzer: when the base is a name, when the step is a name and when the number of iterations isn't known. If the base is a name and it is not possible to have a bound on its value, then even if we know that the loop runs a constant number of times, we cannot infer that the sequence will not overflow. The same is true for an unknown step and for an unknown number of iterations. We can also have some more information on the base and step from the range of their type. This is not yet implemented in chrec_convert, but it will not catch enough cases if we'll have to stop using the aggressive convert. > Perhaps also limiting that test to unsigned types. > yes, there is a test for flag_wrapv in chrec_convert: it calls scev_probably_wraps_p.
