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.
Note the interesting places in VRP where it assumes undefined
signed overflow is in compare_values -- we use the undefinedness
to fold comparisons.
Richard.
