Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gabriel Dos Reis]

"Richard Guenther" <address@hidden> writes:

| On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
| <address@hidden> wrote:
| > "Richard Guenther" <address@hidden> writes:
| >
| > | On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| > | <address@hidden> 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