On 11/09/2014 04:33 PM, Eli Zaretskii wrote: > Why off-list? User error. Re-adding the list. >> Date: Sun, 09 Nov 2014 16:23:00 +0000 >> From: Daniel Colascione >> CC: haroogan@gmail.com >> >>> There's nothing wrong with the address space, and there's nothing >>> wrong with GCC, either. What we have here is a genuine bug in our >>> code, albeit one that is subtle, and also very hard to actually >>> reproduce in real life. >> >> How can this be a bug in our code? > > Because whoever wrote that loop intended it to stop and bail out at > 0x00100000. And that cannot happen with unsigned subtraction. Sure. And the fix you installed is good, but the bug shouldn't have caused GCC to reduce the loop to one iteration. >>> It looked like a GCC bug at first, but as I tried to modify the source >>> and look at the effect of that on the generated code, it finally >>> dawned on me: GCC's loop-unrolling code simply correctly calculated >>> that with the initial value of 0x68000000 and decrement of 0x00800000, >>> the value of 'size' in the loop will never be less than 0x00100000, >>> due to wraparound in the subtraction of unsigned values. So what we >>> have here is a potentially infinite loop, i.e. "undefined behavior". >> >> I don't think the compiler is justified in making this optimization. >> Since when is an infinite loop undefined behavior? GCC has no right to >> alter program semantics in this case, loop unrolling or no. > > OK, I'm not a C Standard lawyer, so I won't argue here. It's enough > for me to know that the trivial fix I installed makes the code work > even under -funroll-loops, and that it fixes a real problem in our > code. Sure, as well as exposing one in GCC.