On Sat, 1 Mar 2008, Joseph S. Myers wrote:
> 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.
Sure, the only clean way to do this is to introduce new tree codes for
trapping arithmetic. Then the usual mechanisms of omit_one_operand
and friends like tree_could_trap_p can work. VRP can for example then
optimize trapping codes to non-trapping codes.
Richard.
