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]
