This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][4.3] Deprecate -ftrapv


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]