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

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> "Richard Guenther" <richard.guenther@gmail.com> writes:
>
> | On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
> | <gdr@integrable-solutions.net> 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.