> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
> On Sat, 18 Jun 2005, Paul Schlie wrote:
>
>> 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:
>
> You appear to have confused unspecified behavior (where the possibilities
> are bounded) and undefined behavior (where the possibilities are
> unbounded). On *undefined* behavior (such as signed integer overflow),
> *this International Standard imposes no requirements*. If a program
> execution involved undefined behavior, *there are no requirements on its
> execution, even before the undefined behavior occurs in the abstract
> machine*.
No, the standard clearly states that it imposes no requirements on the
behavior which an implementation may choose to implement for (and limited
to) that specific undefined behavior; as regardless of that behavior, it's
resulting side effects clearly remains constrained by the rules as specified
in 5.1.2.3.
[#1] Behavior where this International Standard provides two
or more possibilities and imposes no requirements on which
is chosen in any instance. 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 subclause 5.1.2.3.
> Therefore the compiler assumes that you only ever pass it
> programs which do not execute undefined behavior. If a possible execution
> might involve undefined behavior, the compiler presumes that the
> programmer knows more than it can prove and knows that the relevant
> circumstances cannot arise at execution.
The compiler is free to presume whatever it desires as long as the
evaluation of the resulting code it produces conforms to the requirements of
the language. Therefore any compiler which does not consistently treat the
side effects (if any) resulting from the evaluation of an undefined behavior
past the sequence points logically bounding that behavior is non-conformant.
> For example, a correct program
> never involves overflow of a signed loop variable, so the compiler
> presumes that the programmer proved that the loop variable can never
> overflow at execution and uses this information to optimize the loop: it
> cannot prove it by itself but using the presumption that the program is
> correct it can optimize the program better.
As program which may specify/invoke an undefined behavior remains a correct,
albeit non-portable and even possibly indeterminate, program; its arguably
incorrect for a compiler to presume otherwise, however is free to choose
an arbitrary behavior for any specified undefined behaviors specified in the
code, but remains bound to consistently treat the resulting side-effects of
whatever behavior it choose to implement in the evaluation of the program
past the sequence point those side-effects remain bound by.
Therefore, given your example; regardless of what value an implementation
chooses to logically assign to an overflowed loop iteration variable, the
compiler can't assume it's X for the purposes of optimization when in fact
it was assigned the value Y past the sequence point that operation remains
bounded by, as this would violate the sequence rule semantics imposed on all
expression evaluations, regardless of their individual semantics, and
possibly result in non-conformant erroneous behavior.
> The traditional form of undefined behavior is for demons to fly out of
> your nose. We just haven't yet got -fnasal-demons working reliably but it
> would be conforming for it to be on by default. If you are lucky, it will
> happen anyway without that option.
As long as all side-effects are logically expressed at it's sequence point
bounds, I've got no problem with this :)
