autoconf-patches
[Top][All Lists]
Advanced

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

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


From: Gabriel Dos Reis
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: 31 Dec 2006 12:42:57 +0100

"Richard Guenther" <address@hidden> writes:

| On 12/31/06, Richard Kenner <address@hidden> wrote:
| > > What would you suggest this function to do, based on your comments?
| >
| > I'm not familiar enough with VRP to answer at that level, but at a higher
| > level, what I'd advocate is that the *generator* of information would track
| > things both ways, assuming wrapping and non-wrapping semantics (of course, 
if
| > -fwrapv or -fno-wrapv was specified, it would only do that one).  Then the
| > *user* of the information would decide which one to use by applying
| > heuristics based both on the likelihood that the programmer would be relying
| > on wrapping and the importance from an optimization standpoint of not doing 
so.
| 
| For the VRP case I'd like to rework vrp_int_const_binop to behave like
| int_const_binop (that wraps) and return if the operation overflowed.  It's
| much more readable to have the handling (or not handling) of overflow
| at the callers site extract_range_from_binary_expression.  Using
| TREE_OVERFLOW as present is just wasting memory as an extra return
| value will also do.
| 
| So in the end it's probably time to re-work the core implementation of
| int_const_binop to be more like
| 
| tree int_const_binop (enum tree_code code, tree type, tree arg1, tree arg2,
| int notrunc, bool *overflow);
| 
| as it has all the magic to detect overflow already.

Can I interpret that as you volunteering to do it, or at least help?

-- Gaby




reply via email to

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