"johnmatthews2000" <jm5...@...> wrote: > Paul Herring <pauljherring@> wrote: > > > > Since you're messing with undefined behaviour, why would > > you expect any particular behaviour? > > Because I would expect the compiler writers to do whatever > is easiest - wouldn't you?
In days gone past, perhaps, but modern optimisers are much more complicated. They often do cost based analysis of multiple execution paths. The resultant assembler is (often supposed to be) the fastest code. Source code exhibiting undefined behaviour (and that has no implementation specific meaning) adds considerable leeway to cost evaluations. > Probably my understanding of 'easiest' is incorrect, in which > case I would like to know what it is the code is actually > doing. If I understood x86 assembler I would try generating it. Which is a bit like trying to figure out the nature of abattoirs by examing a hamburger paddy. Disassemblies will give you the result, but they often won't tell you why it is the result. Even compiler writers can struggle to tell you _exactly_ how their implementation arrived at a given piece of assembler from a given piece of source code. The easiest thing for a compiler to with a constant is often to propogate it, rather than generate code to allocate memory, put in a constant, then read from it each time it's referred to. Similarly, a non-aliased (non-volatile) object should retain it's last value. So if you assign a variable a constant value, then a compiler can propapogate that constant too. If an alias refers to a constant, then modifying that constant through that alias is undefined. All bets are off. The compiler is not obligated to honour the assurance that would normally come with the assignment. So the easiest thing is to pretend the assignment never occured. If the alias is later referenced for it's value, then the easiest thing for a compiler to do is assume the last stored value if known, especially if it's a constant. -- Peter
