Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar <dewar at adacore dot com>]

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.

Given that there are no predefined semantics requiring exceptions in
C, it would not be terrible to have the same semantics in C if there
are some cases where this is unavoidable (I agree it would be preferable
to avoid these kinds of "optimizations", even in Ada, it's probably
cleaner to catch the intermediate overflow. It's hard to believe the
performance degradation is significant, and if you are really concerned
about this in Ada, you can turn off checks (locally or globally).
> (If we go with converting trapping arithmetic at gimplification time, we 
> could also avoid doing much folding before gimplification with -ftrapv, 
> and so maybe avoid needing to treat all arithmetic as having 
> side-effects.)

Sounds better if it works