This is the mail archive of the 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

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
(650) 331-3385 x713

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