"Richard Guenther" <[EMAIL PROTECTED]> writes: | On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis | <[EMAIL PROTECTED]> wrote: | > "Richard Guenther" <[EMAIL PROTECTED]> writes: | > | > | On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis | > | <[EMAIL PROTECTED]> wrote: | > | > /* Wrapper around int_const_binop. If the operation overflows and we | > | > are not using wrapping arithmetic, then adjust the result to be | > | > -INF or +INF depending on CODE, VAL1 and VAL2. */ | > | > | > | > static inline tree | > | > vrp_int_const_binop (enum tree_code code, tree val1, tree val2) | > | > [...] | > | > | > What would you suggest this function to do, based on your comments? | > | | > | The function should be looked at in the context of the few callers - this | > | is really one of the more ugly and tricky parts of VRP. | > | > I've done that; I do not see an obvious way to make everybody happy -- | > except issueing a warning (which I've done). That is why I was asking | > since you raised that particular point. Maybe VRP experts may have | > opinions... | > | > The heavy (and sole) user of vrp_int_const_binop() is | > extract_range_from_binary_expr(). | | Yes. I don't see a way to issue a warning there without 99% false | positives there. The only thing we can really do is avoid false | positives reliably if we have a + b and known ranges for a and b | so we can see it will _not_ overflow. But issuing a warning only | if we are sure it _will_ overflow will likely cause in no warning at | all - the interesting cases would be those that will have many | false positives.
for this specific function (vrp_int_const_binop), I'm issuing a warning inside the else-if branch that tests for the overflowed result. I'm unclear why that is a false positive since the result is known to overflow. Could you elaborate? | Note the interesting places in VRP where it assumes undefined | signed overflow is in compare_values -- we use the undefinedness | to fold comparisons. I considered compare_values(), but I concluded that issueing a warning from there will yield too many false positive, and probably many duplicates. Is that assumption correct? I have been looking into infer_loop_bounds_from_signedness() called from infer_loop_bounds_from_undefined(). At some places, nowrap_type_p() is used but this function operates only on types, so there will be too many false positive there; yet we will miss warning through that case. -- Gaby
