Just found there were also problems with the C optimizer.
while (True) { if (var) { do1(); } else { do2() }; }
got translated at the machine level into something like
if (var) { while (True) do1() } else { while (True) do2() }
Well, it looks strictly equivalent to the original code to me? But as newbrain said, factoring out the "if (var)" test is an obvious optimization here. It's equivalent, but more efficient.
As long, of course, as "var" doesn't change values while this piece of code executes.If OTOH "var" can change values during the loops, then I'd agree this optimization is wrong. But you seem to be certain "var" is always true here, so the optimization would be correct.
since "var" is expected to be always True then do2() is expected to be dead code, kept in the source for documenting reasons, and I was seriously surprised to see it running.
If the "else" part is executed, then obviously 'var' is false at some point - at least the translated code you mention here can't mean otherwise. You should probably use a debugger or something to figure out WHY do2() is executed. A conditional breakpoint on "var" becoming false would be interesting here. You might have assumed it's always true, when it may not be.
If the behavior is different between optimized and non-optimized code, then I would suspect something wrong about how "var" is handled, but not about this piece of code, which again, unless I missed something, is strictly equivalent to the original code.
The fact the compiler doesn't strip off the "else" clause seems consistent with the fact you see it running at some point. Likely the optimizer didn't detect that "var" was always true, and the execution seems to be consistent with that. It isn't.
We'd probably need to see the rest of the code, because this short piece doesn't tell us anything much, but there's something fishy with "var". Clearly.
One possible cause - just a guess as I don't know anything about "var" - would be that "var" is some global variable, that can change values but has not been qualified volatile. Then the compiler's optimizer is allowed to compile the piece of code you mentioned as you saw. But then it would mean that "var" can actually change values somewhere else - for instance inside an interrupt, or another thread, something like this. If this could be the case, then the solution would be to qualify "var" as volatile to guarantee the correct compilation of this.
If this is not the case, another possible cause, even simpler, would be a missing or incorrect initialization of "var".
Unless the optimizer is completely buggy, what you seem to witness could be explained by the above. If the optimizer factors out the "if", then it means it assumes "var" doesn't change values while the loops execute, which would be the case if "var" is just a local variable, or a global, non-volatile-qualified variable. Then if the optimizer doesn't prune the "else" clause, it further means it had no way, from static analysis, to know that "var" is always true.
All this should give you things to look at in the code.