Re: [PATCH][4.3] Deprecate -ftrapv

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> 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.