[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Guenther
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sun, 31 Dec 2006 00:30:34 +0100

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

The heavy (and sole) user of vrp_int_const_binop() is

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]