This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc trunk vs python
On 8/27/06, Guido van Rossum <guido@python.org> 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";