Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar <dewar at adacore dot com>]

Richard Guenther wrote:

> IMHO this semantics asks for the frontend to implement the overflow
> check.  Does the above mean that Ada does intermediate arithmetics
> in wider types?  I don't see how you could catch the B + C case
> otherwise (assuming the range check for the assignment to A covers
> all of As range of valid values).

So here's exactly what happens now in Ada

1. If -gnato is not set (no overflow checking)

In this case, the situation is exactly the same as C, and the front end
ignores the possibility of overflow. The official Ada semantics are that
if you suppress overflow checks, and an overflow occurs (intermediate or
otherwise), the executino is erroneous (undefined in C-speak). So Ada
with checks off is in all respects identical to C semantics. No problem.

2. If -gnato is set (overflow checking on)

In this case, the front end does generate all overflow checks (there
is an example of this earlier in the thread from me, which shows
the original Ada source, the pseudo-Ada expanded source from the
front end, and the final assembly. In this mode, we don't bother
trying to allow cases like (B*C)/D, if the B*C overflows it will
raise an exception.

The approach is to do double length arithmetic and range check
the result, unless we are at 64-bits, in which case we call
library routines that do the arithmetic overflow checking.

Note that in Ada, you can often avoid one or both ends of
the range check, e.g.

    type R is integer range 1 .. 10;

    RV : R;

    R := R + 1;

no need for double length arithmetic here, you just check that the
result is not greater than 10.

Now of course what we would hope for is a back end -ftrapv mode
that at least in some cases on some targets is more efficient,
e.g. in -gnatOs mode at least on the ia32, we would generate
INTO instructions, and on the MIPS trapping adds.
> Richard.