> 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.
I'd be in favor of flags rather than new codes. For the most part, all processing of non-trapping operations and trapping operations are the same and we already have predicates for when operations trap that we can use to tell the difference. I think that flag aproach would be far less work because adding new operations to all the various switch statements is a lot of work. > 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. You forgot the third: if Ada is to use it rather than its own approach, it must indeed be 100% reliable. Robert is correct that if it's sufficiently more efficient than Ada's approach, it can be made the default, so that by default range-checking is on in Ada, but not in a 100% reliable fashion. This means there's be three states: explicitly enabled, using Ada's mechanism, suppressed, using neither, or the default, using GCC's. But if GCC's mechanism also did things like called functions that did special arithmetic, there'd be no point in Ada using this.
