Re: basic VRP min/max range overflow question

[Paul Schlie <schlie at comcast dot net>]

Sorry, yes the quote below defines unspecified, not undefined behavior.

Now more correctly:

       [#1] Behavior,  upon  use  of  a  nonportable  or  erroneous
       program  construct, of erroneous data, or of indeterminately
       valued  objects,  for  which  this  International   Standard
       imposes  no  requirements.   Permissible  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).

       [#3] The implementation must successfully translate a  given
       program  unless  a syntax error is detected, a constraint is
       violated, or it can determine that every possible  execution
       of that program would result in undefined behavior.

Which again is specific to that which is defined, as it requires the
successful (and presumably conformant) translation of the program unless
the implementation can prove the whole program is itself would have an
undefined behavior (reinforcing the notion that the language's semantics
remain in force even in the presence of a expression with undefined
semantics).


> From: Paul Schlie <schlie@comcast.net>
>> From: "Joseph S. Myers" <joseph@codesourcery.com>
>> 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 :)