<div dir="ltr">I guess this doesn't matter too much in the grand scheme of things, but I'm somewhat confused by it, so I thought I'd ask.<div><br></div><div>Specifically, the reporter of that issue, calling themselves "Alexander", used the following program as an "example" of what they called "too aggressive optimization":</div><div><br></div><div>program test:<br>var v:longword;<br>begin<br>   if v=2 then while true do ;<br>end.<br></div><div><br></div><div>To me, that just shows a while loop that will very obviously be exited immediately in all cases, because "v" is very obviously *not* equal to 2. Yet they used a (tiny) snippet of assembler from this and deemed it "incorrect", without making any attempt to clarify what they meant.</div><div><br></div><div>Generally speaking, I would expect any compiler that is *capable* of realizing that the while loop has zero chance of *ever being entered at all* in the first place to remove the loop from its final codegen entirely, because there's no logical reason for it to be there.</div><div><br></div><div>As far as I can tell, FPC is not (yet) such a compiler. That said, that's not really such a big deal, because it obviously still immediately determines that it shouldn't even *start* the loop and proceeds as normal.</div><div><br></div><div>So yeah: basically, the bottom line is I don't quite see what Jonas determined to actually *be* a bug on display in that particular issue, at all. To me it demonstrated nothing but a program that blatantly did exactly what it obviously would do.</div><div></div></div>