Re: basic VRP min/max range overflow question

[Paul Schlie <schlie at comcast dot net>]

> From: Michael Veksler <VEKSLER@il.ibm.com>
>> Paul Schlie <schlie@comcast.net> wrote on 20/06/2005 16:09:16:
>>> From: Michael Veksler <VEKSLER@il.ibm.com>>
>>> As for overflow, you can say that you want instead of "undefined"
>>> to treat is "unspecified". Where each architecture / opsys / compiler
>>> must consistently define what happens on overflow:
>>>  - saturation
>>>  - wrap 2's (or 1's) complement
>>>  - exception.
>> 
>> - yes, effectively I don't perceive any necessity for undefined, vs
>> unspecified; as I don't perceive any necessity to give the compiler
>> the freedom to treat generate an arbitrary program which may contain
>> a potentially ambiguous specific and isolatable behavior. Again, is
>> seems real simple to abide by C's sequence point and as-if rules to
>> contain any ambiguity to the bounds between it's logical sequence points,
>> and any resulting side-effects specific to that ambiguity must be expressed
>> and logically bounded there.
> 
> Look again at my dangling pointer example. In this example, the most
> benign optimizations may "generate an arbitrary program" in this case.
> As I said, and as Robert Dewar concurred, you can carefully define
> something less strict than "undefined" on a case by case basis.
> On the other hand, it is impossible to make all "undefined" cases
> demonstrate an "isolatable behavior". Such a broad requirement is
> impossible to fulfill, as my dangling pointer example shows.
>
> ... Dangling pointer may or may not lead to the corruption of the code
> itself (self modifying code). When that inadvertently happens, all bets
> are off. It is possible that by pure luck the code is "safe" without
> optimization, and after optimizing unrelated stuff the code becomes self
> destructive.

For what its worth, I don't consider this a problem, as long as the
semantics (including the relative sequencing) of any dangling pointer are
preserved in the process, regardless of the potentially unpredictable and/or
dire consequences they may have.

As it is just this uncertainty which I view as the basis of compiler's
constraint; as unlike the apparently popular view that something which is
un/ill-defined provides license to modify specified code in any way desired;
I view the uncertainty as a constraint which forbids the compiler from
presuming it's reference will store or return any predictable value,
therefore can not be used as a basis of any optimization, therefore must
preserve whatever unpredictable behavior may result upon it's execution
within some potentially arbitrary environment, while continuing to presume
that the remaining program semantics and state are preserved, therefore may
continue to be optimized based upon any predictable side-effects which are
not logically dependant on dangling pointer references.

Thereby strictly preserving the program's semantics as authored, as
potentially unpredictable and possibly unrepeatable as the resulting
behavior may be; as I perceive to do otherwise as being inconsistent with
the program as authored, although would expect a suitable warning alerting
the programmer of it's likely unintended potential consequences if a
dangling pointer references are identifiable; where if not, then all things
remain the same, i.e. only known safe optimizations are enabled to be
performed which by definition precludes any dependant on unpredictable value
ranges and/or behaviors.