Jean-Marc Bourguet <jm_at_[hidden]> writes:

| On Thu, 24 Oct 2013 09:02:38 +0000, Gabriel Dos Reis
| <gdr_at_[hidden]> wrote:
|
| > | And no improvements for programmers who want to write portable code.
| >
| > Lawrence, I would like to understand the kind of optimizations
| > you have in mind that we would lose if signed integer arithmetic
| > overflow is 'unspecified' as opposed to 'undefined behavior'.
|
| I seems to me that any flow analysis which propagate back information
| assuming there is no overflow would not be possible with unspecified
| behavior. If I'm right, undefined allows to remove the if, unspecified
| doesn't.
|
| if (i == INT_MAX) {
| // something
| }
| ++i
|
| Yours,

Part of the complaints, and indeed the original motivation for this
Study Group, is that people are unhappy with "arbitrary" code removal
based on the fact that a construct invokes undefined behavior "down the
road" when it hasn't been executed yet (but is on a must-execute path.)

[ Note I wrote "abritrary" in quotes. ]

"unspecified behavior" means:

    behavior, for a well-formed program construct, correct data, that
    depends on the implementation [Note: The implementation is not
    required to document which behavior occurs. The range of possible
    behaviors is usually delineated by this International
    Standard. --end note ]

In your example, you are correct that a compiler is permitted to remove
the if-statement if i has the value INT_MAX. However, if i does not
have the value INT_MAX, a conforming implementation cannot remove that
if-statement. My question is whether we would lose any useful
transformations/optimizations (for programs we care about) that would be
made much harder to apply if we required 'unspecified behavior'. I
suppose a subsidiary question is whether INT_MAX is considered 'correct data'
for the operation "++i".

-- Gaby