On Sun, 2 Mar 2008, Mark Mitchell wrote: > 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.
Nice plan. Though I doubt that even this simple one will be carried out, as even the simple bugs in the current implementation stay around for at least 5 years. Even I think that there are more useful things to spend time on than making -ftrapv work. Especially fixing its counter-part, -fwrapv, thus the encoding of integer overflow in our IL, should be tackled with higher priority. With the same solutions basically - add variants of the tree codes to note "may overflow". I believe at last years summit Ian told me that someone at google was working on this -- Ian is this still true? Thanks, Richard.