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.
