On Sat, 1 Mar 2008, Richard Guenther wrote:

> > You also need to deal with fold, which will optimize away potentially 
> > trapping computations with -ftrapv and runs before gimplification 
> > (possibly in association with making fold run at gimplification time and 
> > not before).
> 
> It should not - at least we have various tests in place to ensure fold
> does not remove traps nor insert traps.  Of course this is a very badly
> tested part of the compiler, so possibly both may happen.

But arbitrary arithmetic expressions aren't marked as potentially trapping 
/ having side-effects with -ftrapv, so cases such as

int f(int a, int b) { return 0 * (a + b); }

get the potentially trapping arithmetic folded away.  If -ftrapv is to 
have properly defined semantics, those must include trapping if (a + b) 
overflows in the above code.

(If we go with converting trapping arithmetic at gimplification time, we 
could also avoid doing much folding before gimplification with -ftrapv, 
and so maybe avoid needing to treat all arithmetic as having 
side-effects.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Reply via email to