Summation on HP 42S

[Thomas Okken]

On re-reading this thread, I realize that I lost sight of my own argument, and the example provided by ijabbott is indeed incorrect code that manages to do the right thing only when not optimized! Urr. I therefore concede that such code can exist.

I remain skeptical, though, of ijabbott's claim that this kind of failure represents the *general* case of optimizer-induced faults. Keep in mind that buggy optimizers are capable of making perfectly good code fail, which means they can potentially affect everything, not just code written with poor assumptions.

The first time I ran into such a bug in Free42 was in the code that initialized one of the lookup tables used for binary/decimal conversions in versions before 1.5. This code worked fine on all platforms except Windows, where the main loop exited one iteration too late. I stepped through that code with the debugger and watched the loop counter reach its end value, and the loop continuing with one more iteration anyway. I eventually got it to behave by inserting compiler directives disabling the optimizer around the function in question.

(I never reported that bug, partly out of laziness, and partly because the compiler I was using, Visual C++ 6.0, was ancient even back then.)