Re: basic VRP min/max range overflow question

[Paul Schlie <schlie at comcast dot net>]

> From: Michael Veksler <VEKSLER@il.ibm.com>>
>> Paul Schlie wrote on 20/06/2005 14:13:33:
>>> From: Robert Dewar <dewar@adacore.com>
> ...
>>> Note that in the cases where something is statically optimized away
>>> (these are the easy cases), it is nice if the compiler warns that this
>>> is happening that would certainly be the case in Ada in the corresponding
>>> situation, not sure about C++). But of course no such warning is required.
>> 
>> Agreed. And given that the standard enables an implementation to do
>> anything
>> upon encountering an undefined behavior, it just seems just as correct to
>> simply presume that the behavior will be consistent with the targets
>> native
>> behavior; as just because it may enable the compiler to do anything, it
>> doesn't imply that it should, or that it would be a good idea to do so.
>> 
> 
> Agreed in theory. Can you define "to do anything" ? What aspects
> of the language can be defined as "native behavior"? What aspects
> are always undefined? (e.g. uninitialized pointer dereference?).
> 
> 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.

> You can argue (and maybe show benchmarks) that the above
> "unspecified" does not inhibit too many real world optimizations,
> as compared with "undefined". If that were the case, you would
> have a chance convincing the std and gcc of your views.

- can one show that it is unreasonable?

> However, generalizing things for all "undefined behavior" is
> doomed to failure. Not all "undefined behaviors" were born equal,
> and you can't treat them as equal, unless they
> "enable the compiler to do anything".

- example?

> You can be pragmatic, and try hard to minimize the cases where
> the compiler happens "to do anything", but you cannot formally
> guarantee that it will never happen. If you are not careful you may
> end up with a spaghetti compiler full of special code geared
> at the avoiding many of the "to do anything" cases.
> 
> 
>   Michael
>