On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: ...
I have not received reports about bugs in the offending code when compiled with other compilers.
I do know at least one another compiler that does this, and at least one significant project (which is actually quite a bit larger than Python) that suffered similar problem as Python's suffering - in short, this isn't new and this isn't even something gcc specific (or fault). And Python isn't the first program that suffers from this either.
> code. But this particular optimization will let us do a much better > job on very simple loops like > for (int i = 0; i != n; i += 5) > The issue with a loop like this is that if signed overflow is defined > to be like unsigned overflow, then this loop could plausibly wrap > around INT_MAX and then terminate. If signed overflow is undefined, > then we do not have to worry about and correctly handle that case. That seems to me rather obviously broken code unless the programmer has proven to himself that n is a multiple of 5. So why bother attempting to optimize it?
There are legitimate code with similar form, like pointer increment compared against the "end" pointer which happens often in string manipulation or buffer management code. More importantly some of C++ STL iterators often end up in such a form. -- #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
