Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell <mark at codesourcery dot com>]

Joseph S. Myers wrote:

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

> They are the natural interpretation of -ftrapv that's simplest to describe 
> in terms of the abstract machine of the C standard: any signed integer 
> arithmetic overflow in the abstract machine (and maybe integer division by 
> 0, signed or unsigned) should be guaranteed to yield a trap at runtime.

I agree with everything you've written, including, in particular, that 
making this explicit in the IL (via special tree codes for, e.g., 
trapping-add) would be best.

However, I don't think doing all of that work is required to make this 
feature useful to people.  You seem to be focusing on making -ftrapv 
capture 100% of overflows, so that people could depend on their programs 
crashing if they had an overflow.  That might be useful in two 
circumstances: (a) getting bugs out (though for an example like the one 
above, I can well imagine many people not considering that a bug worth 
fixing), and (b) in safety-critical situations where it's better to die 
than do the wrong thing.

But, I think that (a) has been the most common use of -ftrapv, and for 
bug-detection, it's not vital that we get 100% of the overflows. 
Detecting some/most bugs is a lot better than nothing!

If you set the bar for the feature too high, we may end up not having 
-ftrapv at all -- because nobody gets around to implementing it -- 
rather than having an -ftrapv that catches some, but not all overflow 
errors.  And that seems unfortunate.

I think there's a staged implementation plan here that delivers value 
early, but still allows us to gradually progress towards the ideal state 
over time.  In particular:

1. Move the checks from expand to GIMPLE, turning them into explicit 
checks in the IL, or into calls to library functions (but not necessary 
libcalls per se).  This might be more expensive at run-time than the old 
implementation, but no worse than what the Ada front-end is already doing.

2. Introduce new tree codes and change the GIMPLE code to only insert 
the checks for operations using those codes -- but after gimplification 
these tree codes are no longer used.

3. Plumb the new operations through the TREE-SSA optimizers, add support 
for generating the checks during expand for those trapping operations 
that make it to that point, and disable the insertion of checking at 
GIMPLE-time.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713