[PATCH][4.3] Deprecate -ftrapv

Robert Dewar dewar@adacore.com
Sun Mar 2 19:31:00 GMT 2008


Ross Ridge wrote:

> Actually, that's a different issue than catching 100% of overflows, 
> which apparently Ada doesn't require.

Well basically Ada does require catching all overflows, the only issue
is the optimization issue that we already discussed, it would be
acceptable to not catch this.  However, if we write:

   X := Y + Z;

then Ada demands we catch overflow with 100% reliability, so it really
depends on whether we can accurately characterize the cases in which
-ftrapv "fails".

Note that for static expressions:

    X : Integer := 9817236498761928736498712334 * 123412334 /
                     918273649876123938474698172364;

The Ada standard requires computation in infinite precision, it would be
wrong to catch intermediate overflow, but the Ada front end takes care
of all that.

>> 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.
> 
> On the issue of performance, out of curiosity I tried playing around
> with the IA-32 INTO instruction.  I noticed two things, the first was
> that instruction wasn't supported in 64-bit mode, and the second was
> that it on the Linux I was using, it generated SIGSEGV signal that was
> indistinguishable from any other SIGSEGV.  If Ada needs to be able to
> catch and distinguish overflow exceptions, this and possibile other
> cases of missing operating support might make processor specific overlow
> support detrimental.

Usually there are ways of telling what is going on at a sufficiently
low level, but in any case, code using the conditional jump instruction
(jo/jno) is hugely better than what we do now (and it is often faster
to usea jo than into).
> 
> 					Ross Ridge



More information about the Gcc mailing list