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

[Paul Schlie <schlie at comcast dot net>]

> From: Robert Dewar <dewar@adacore.com>
> 
> Paul Schlie wrote:
> 
>> As although C/C++ define some expressions as having undefined semantics;
>> it would seem desirable to be able to conveniently force GCC to presume
>> a target's true native semantics in lieu of presuming their being undefined.
>>  
> As a general principle this is completely meaningless, since it presumes
> an obvious mapping from C++ semantics to the "target's true native semantics"
> [a pretty meaningless phrase].
> 
> So this only makes sense for very specific cases of undefinedness, and
> you have to very clearly state what you are suggesting for that particular
> case.
> 
>> (i.e. Enable a target to define it's native overflow, null-dereference, etc.
>> semantics, which may be optionally utilized as the basis of optimization.)
>>  
> I assume you are misusing i.e. here to mean "for example", but even so,
> these examples are not particularly useful.

(no I meant "id est"/"that is", although could possibly have chosen better)

- However regardless; although I understand the desire to improve compiled
  code performance by potentially altering non-formally-portable behaviors;
  I admittedly remain confounded by an apparent lack of understanding that
  there are clearly circumstances when it is more desirable to maintain a
  program's performance optimized behavior, although it may not be warranted
  to be portable across arbitrary targets; such as in circumstances when it
  is imperative that a verified behavior of code at a particular level of
  optimization for debugging and/or verification purposes hypothetically,
  must remain functionally equivalent when compiled at a different level of
  optimization or risk failure; or in circumstances when it may be desired
  to utilize a compiler as an high-level language assembler, implying that
  the compiler's optimizations should ideally be more sensitive to a
  particular target machine's factual implementation semantics, than may be
  formally warranted by a source language itself.

- Are there any particular formally "undefined" language semantics you
  perceive as being difficult associate with an alternatively well defined
  target specific implementation behavior?  As if not, I can only interpret
  your response as being itself both seemingly unfounded and meaningless.