This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][4.3] Deprecate -ftrapv
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