> From: Robert Dewar <[EMAIL PROTECTED]> > > 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.
