Re: New no-undefined-overflow branch

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 26 Feb 2009, Richard Guenther wrote:

> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.

So you would have both wrapping and no-overflow versions of these codes 
(with it of course always being valid for a transformation to convert the 
no-overflow version into a wrapping one if in a particular case that is 
beneficial), and the gimplification process would select which codes to 
use based on the -fwrapv setting?  Whereas trapping versions (any 
reimplementation of -ftrapv) would be expected to be implemented at 
gimplification time or before with explicit checks in GIMPLE rather than 
further variant codes?

(RTL has only the overflow-wraps operation variants, as well as having 
signed/unsigned operations where necessary instead of signed/unsigned 
types.  (It has overflow-traps versions as well in the present -ftrapv 
implementation.))

If anyone were to wish to make -fwrapv get INT_MIN / -1 and INT_MIN % -1 
right (see the discussions in PR 30484), where would this fit in this 
scheme?  Different operations for division and modulo operations according 
to whether these cases are defined, and a lowering stage carried out on 
GIMPLE at some point to convert the versions where they are defined to the 
versions where they aren't (inserting explicit checks for -1) if the 
underlying target instructions do not make these operations defined?  
(Both variants would embed an assumption that you are not dividing by 
integer 0.)

Making these semantics explicit in the IL instead of in global flags is of 
course a good thing.

-- 
Joseph S. Myers
joseph@codesourcery.com