The compiler is "trusting the programmer" the programmer to never run undefined behaviour. The language trusts the programmer in the sense that casts are not checked.
I don't see anything in your link that defends the interpretation of "trust the programmer" as meaning that compiler should emit obvious assembly. Do you have a supplemental reference?
There are a large number of reasons that a compiler should not emit the obvious operations on ordinary 2's complement hardware, as I have wide freedom to choose the contents of the "...". It ranges from the very obvious ("x = 0;" so constant folding occurs and blocks emission of the negation, or 'x' is never used again so dead code elimination blocks emission of the negation) to the less obvious (~x is used in multiple calculations in different expressions) to the downright hard to reason about.
What semantics does "issue the underlying machine instructions and return whatever result they provide" have? What about template non-type arguments? Constant expression evaluation? Used in the size of an array?
What if the compiler uses "whatever the machine does" when determining the size of an array as part of compilation, then we copy the resulting program to a different computer that claims to have the same ISA, but where "whatever that machine does" happens to be different. (This situation would be surprising for integer arithmetic, but did occur for x86 floating point arithmetic.) Are you okay with the compiler evaluating one size for an array at compile time, but calculating a different size for the array at run time?
What if I tell you, for the sake of argument, that compilers today are already following your proposed rule: since you didn't specify which instructions to issue, you have no standing to complain about the instructions the compiler chose. Can you fix this without adding a listing of CPU instructions to the language standard and without fully defining it?
Suppose I have a function with two local variables, "int x, y;" and I take &x, I can use x (or x[-1]) to make changes to 'y'?
And similarly, I can construct a pointer to stack variables in another call stack frame whose address was never taken? As long as I can cast the right integer to a pointer?
Given these rules, when would it be valid to move automatic local variables into registers? Only when there are no opaque pointers used and no opaque functions called?
ub mailing list