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

[Richard Guenther]

On 31 Dec 2006 00:40:39 +0100, Gabriel Dos Reis
<address@hidden> wrote:
> "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?

Well, we use that function to do arithmetic on value ranges like
for example the ranges involving the expression a + b

[50, INT_MAX] + [50, 100]

now you will get a warning as we use vrp_int_const_binop to add
INT_MAX and 100 (to yield INT_MAX in the signed case).  Of
course adding a + b will not always overflow here (it might never
as the INT_MAX bound might be just due to VRP deficiencies),
for example 50 + 50 will not overflow.

So using vrp_int_const_binop to generate the warning will yield
very many false positives (also due to the fact that if we only know
the lower or upper bound we have lots of INT_MAX and INT_MIN
in value ranges).

> | 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?

That is correct - it's basically the same problem as if we were warning
from inside fold.

> 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.

I don't know that area too well, but I think we are already issuing a
warning if we use -funsafe-loop-optimizations, so it might be possible
to do the same if we use signed wrapping undefinedness.  Zdenek
should know more.

Richard.