Re: basic VRP min/max range overflow question

[Paul Schlie <schlie at comcast dot net>]

> Mike Stump wrote:
>> Paul Schlie wrote:
>> - If the semantics of an operation are "undefined", I'd agree; but if
>>   control is returned to the program, the program's remaining specified
>>   semantics must be correspondingly obeyed, including the those which
>>   may utilize the resulting value of the "undefined" operation.
>
> I am sorry the standard disagrees with you:
>
>        [#3] A  program  that  is  correct  in  all  other  aspects,
>        operating  on  correct data, containing unspecified behavior
>        shall be a  correct  program  and  act  in  accordance  with
>        5.1.2.3.
>
> :-(  Maybe you just mean that you'd like it if the compiler should
> follow the remaining semantics as best it can, on that point, I'd agree.

Maybe I didn't phrase my statement well; I fully agree with the cited
paragraph above which specifically says a program containing unspecified
behavior "shall be a  correct  program  and  act  in  accordance  with
5.1.2.3". Which specifies program execution, in terms of an abstract machine
model, which correspondingly requires:

       [#2] ... At  certain  specified
       points in the execution sequence called sequence points, all
       side effects of previous evaluations shall be  complete  and
       no  side  effects of subsequent evaluations shall have taken
       place.

       [#3] In the abstract machine, all expressions are  evaluated
       as  specified  by  the  semantics.  An actual implementation
       need not evaluate part of an expression  if  it  can  deduce
       that  its  value is not used and that no needed side effects
       are produced ...

Therefore regardless of the result of an "undefined" result/operation at
it's enclosing sequence point, the remaining program must continue to abide
by the specified semantics of the language.

> Robert Dewar writes:
> You are forgetting the "as if" semantics that is always inherent in
> the standard. So after an operation with an undefined result, we can
> do anything we like with the value, since it is "as if" the operation
> had produced that value. So for example, if we skip an operation because
> we know it will overflow, and end up using uninitialized junk in a register,
> it is "as if" that undefined operation produced the particular uninitialized
> junk value that we ended up with.
> 
> So the above is inventive but wrong.

No, as above, the standard clearly requires that the side-effects of an
undefined operation be effectively bounded at it's enclosing sequence
points. Therefore any optimizations performed beyond these bounds must be
"as if" consistent with any resulting stored value/state side effects which
may have resulted from an operation's undefined behavior.

Therefore clearly, subsequent evaluations/optimizations must comply with
whatever logical state is defined to exist subsequent to an implementation's
choice of an undefined behavior past it's delineated sequence point if
logical execution is allowed to proceed past them.

Therefore clearly:

- an optimization which presume a value which differs from the effective
stored value past a sequence point may result in erroneous behavior; which
as would be the case in the example I provided.

- an optimization which presumes the execution state of a program does not
proceed past a sequence point. but in fact does, may result in erroneous
behavior; which would be the case if NULL pointer comparisons were optimized
away presuming an earlier pointer dereference would have prevented execution
from proceeding past it's enclosing sequence point if in fact it does not.

> Dale Johannesen writes:
> You are wrong, and this really isn't a matter of opinion.  The standard
> defines exactly what it means by "undefined behavior":
> 
> 3.4.3 1 undefined behavior
> behavior, upon use of a nonportable or erroneous program construct or
> of erroneous data, for which this International Standard imposes no
> requirements
>
> 2 NOTE  Possible undefined behavior ranges from ignoring the situation
> completely with unpredictable results, to behaving during translation or
> program execution in a documented manner characteristic of the environment
> (with or without the issuance of a diagnostic message), to terminating a
> translation or execution (with the issuance of a diagnostic message).

- as above, the logical side effects of an undefined behavior (what ever
  it's defined to be by an implementation) are clearly logically constrained
  to within the bounds of the it's enclosing sequence points.