Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther <rguenther at suse dot de>]

On Sat, 1 Mar 2008, Robert Dewar wrote:

> Joseph S. Myers wrote:
> 
> > But arbitrary arithmetic expressions aren't marked as potentially trapping /
> > having side-effects with -ftrapv, so cases such as
> > 
> > int f(int a, int b) { return 0 * (a + b); }
> > 
> > get the potentially trapping arithmetic folded away.  If -ftrapv is to have
> > properly defined semantics, those must include trapping if (a + b) overflows
> > in the above code.
> 
> Interestingly enough, Ada semantics allow the overflow in this case. The
> rule in Ada is that if an arithmetic operation overflows, it must either
> raise an exception or yield the correct value. Now if you say:
> 
>    A := B + C;
> 
> Then even if you allow an overflowed value for B+C it will be caught
> by the normal required range check on the assignment to A, so this rule
> is really only relevant for intermediate results. A canonical example
> where this rule is likely to be useful is
> 
>    A := B * C / D;
> 
> where it is fine to do a double length multiply followed by a division
> that brings the result back in range, even if B*C is out of range.

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

Richard.