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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

"Richard Guenther" <richard.guenther@gmail.com> writes:

| On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| <gdr@integrable-solutions.net> wrote:
| > kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
| >
| > | > Here's an example from the intprops module of gnulib.
| > |
| > | These are interesting case.
| > |
| > | Note that all the computations are constant-folded.
| > |
| > | And I think this points the fact that we can "have our cake and eat it too"
| > | in many cases.  Everything we're seeing points to the fact that the cases
| > | where assuming undefined behavior for overflow will help optimizations are
| > | cases where few if any sane programmers would write the code depending on
| > | wrap semantics (e.g., loop variables).  And nearly all the cases where wrap
| > | semantics are expected (e.g., the above) are such that there's no reasonable
| > | optimization benefit in assuming they're undefined.
| > |
| > | Take constant folding: if we were pendantic about it, we could say, "this
| > | folded expression overflows and so is undefined, so let's set its value to be
| > | whatever constant would yield the most efficient code in that case".
| > |
| > | Such behavior would be standard-compliant, but as unfriendly as possible
| > | because it wouldn't "optimize" any real code, just break common idioms.
| > | I doubt anybody would suggest not implementing wrapping semantics in
| > | constant folding.
| >
| > As I'm looking into the VRP and CHREC codes to implement the
| > -Wundefined warning, I came across this:
| >
| >    /* 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(). 

-- Gaby