Date: Thu, 30 May 2013 21:24:56 +0200
On 05/29/2013 11:36 PM, Richard Smith wrote:
> On Wed, May 29, 2013 at 12:35 PM, Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
> (1) Is a compiler diagnostic acceptable? Yes.
> (2) Is a run-time abort acceptable? Yes.
> (3) Is an unspecified result value acceptable? Yes.
> (4) Is it acceptable that your compiler changes the behavior
> of unrelated code that follows the overflow? That's very surprising.
>
> Giving compilers latitude to choose among 1-3 (depending on the
> target audience) is fine, but, in my opinion, prohibiting option 4
> would be an improvement.
>
>
> I don't think we should make such judgments before considering all
> the consequences. For instance, there are some optimizations which
> compilers only perform if they can show a loop terminates or compute
> a loop trip count, and the fact that signed overflow has undefined
> behavior allows compilers to prove that some loops terminate. This
> can have very far-reaching benefits which we may not want to lose.
I'd like to learn more about optimizations that are possible here.
Note that option (3) says that *any* (random) value resulting
from a signed integer overflow is fine, so I'd like to understand
the difference between (3) and (4) regarding allowable compiler
optimizations.
Jens
> On Wed, May 29, 2013 at 12:35 PM, Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
> (1) Is a compiler diagnostic acceptable? Yes.
> (2) Is a run-time abort acceptable? Yes.
> (3) Is an unspecified result value acceptable? Yes.
> (4) Is it acceptable that your compiler changes the behavior
> of unrelated code that follows the overflow? That's very surprising.
>
> Giving compilers latitude to choose among 1-3 (depending on the
> target audience) is fine, but, in my opinion, prohibiting option 4
> would be an improvement.
>
>
> I don't think we should make such judgments before considering all
> the consequences. For instance, there are some optimizations which
> compilers only perform if they can show a loop terminates or compute
> a loop trip count, and the fact that signed overflow has undefined
> behavior allows compilers to prove that some loops terminate. This
> can have very far-reaching benefits which we may not want to lose.
I'd like to learn more about optimizations that are possible here.
Note that option (3) says that *any* (random) value resulting
from a signed integer overflow is fine, so I'd like to understand
the difference between (3) and (4) regarding allowable compiler
optimizations.
Jens
Received on 2013-05-30 21:25:15