* Paul Schlie: >> But the assertion is trivially true. If you impose fewer constraints >> on an implementation by leaving some cases undefined, it always has >> got more choices when generating code, and some choices might yield >> better code. So code generation never gets worse. > > - yes, it certainly enables an implementation to generate more efficient > code which has no required behavior; so in effect basically produce more > efficient programs which don't reliably do anything in particular; which > doesn't seem particularly useful?
The quality of an implementation can't be judged only based on its conformance to the standard, but this does not mean that the implementation gets better if you introduce additional constraints which the standard doesn't impose. Some people want faster code, others want better debugging information. A few people only want optimizations which do not change anything which is pracitcally observable but execution time (which is a contradiction), and so on. > - Essentially yes; as FP is an approximate not absolute representation > of a value, therefore seems reasonable to accept optimizations which > may result in some least significant bits of ambiguity. But the same is true for C's integers, they do not behave like the real thing. Actually, without this discrepancy, we wouldn't have to worry about overflow semantics, which once was the topic of this thread! >>> The compiler should be able to statically determine if an >>> expression's operands are interdependent, by determining if any of >>> its operand's sub-expressions are themselves dependant on a variable >>> value potentially modifiable by any of the other operand's sub- >>> expressions. >> >> Phrased this way, you make a lot of code illegal. I doubt this is >> feasible. > > - No, exactly the opposite, the definition of an order of evaluation > eliminates ambiguities, it does not prohibit anything other than the > compiler applying optimizations which would otherwise alter the meaning > of the specified expression. Ah, so you want to prescribe the evaluation order and allow reordering under the as-if rule. This wasn't clear to me, sorry. It shouldn't be too hard to implement this (especially if your order matches the Java order), so you could create a switch to fit your needs. I don't think it should be enabled by default because it encourages developers to write non-portable code which breaks when compiled with older GCC version, and it inevitably introduces a performance regression on some targets.
