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 jos...@codesourcery.com