Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

[Robert Dewar]

Paul Schlie wrote:

>>Gabriel Dos Reis wrote:
>>I predict we will end up changing nothing for GCC; I also predict that
>>he'll be unsatisfied with unsupported claims; then, there is a high
>>chance the discussion will be restarted again in a different form
>>(hey, this is not the first time you, Paul and me are involved in this
>>kind of undefined discussion).  If we have good answers with backed up
>>claims, we could just reference it later.
>>...
>>I think supported answers will help diminish undefined disucssion frequency.
>>If you don't have a definition for "good reason", that is fine.  Let's move
>>on something else; this is a new year.
>>    
>>
>
>Gentlemen, I honestly don't want to promote a frivolous debate either; as
>such, if it is generally agreed there are no valid conceivable reasons to
>enable GCC to allow a target to specify the semantics of its particular
>implementation to enable optimizers to utilize that information such that
>its otherwise non-optimized behavior may be preserved during optimization,
>then I simply accept that I'm alone in the believe of its significance and
>utility; if not, then it seems that the only questions remaining are related
>to how may this be done relatively easily within the current optimization
>and target definition framework?
>
>If specific examples are required, although likely considered obvious,
>here's a few:
>
>- x[y] = 0;                 // may also be undefined if y is one past the
>  if (x[y]) y = y+1;        // extent of x[], and/or result in an overflow
>                            // of x[y] one past the it's upper bound if
>                            // allocated at the upper range of the address
>                            // space, and/or if allocated at the base
>                            // address of 0 and y is 0 or negative; but
>                            // non-the less the machine evaluating the code
>                            // will do something which is likely well
>                            // defined, and must be defined if that logical
>                            // behavior is to be predictable and thereby
>                            // preferable during optimization.
>  
>
We have been through this before, there is no requirement that 
optimization preserve the behavior of
undefined programs (indeed that is often one of the primary motivations 
in making things undefined).
It is fine to argue that defining the semantics is useful in a 
particular case, but arguing solely from the
point of view of trying to preserve observed behaviort is a poor 
argument. Indeed the point is that
optimization is not changing the behavior, the behavior is 
non-deterministic, and can change from
one compilation to the next even if optimization does not change. 

>- x = 5 << z;               // where although implementation specific, must
>  if (x > 0) z = 2;         // to be definable if to be utilized as the
>                            // basis of a target specific behavior
>                            // preserving optimization.
>  
>
ditto