This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc trunk vs python

"Guido van Rossum" <> writes:


| > In general I think I personally am on the very conservative edge of
| > gcc developers, in that I am generally opposed to breaking existing
| > 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?

Because the programmer may have proven that n is multiple of 5, *and*
the above is the result of inlining and removing other abstraction
artefact, e.g. not directly _written_ like that.  Programmers do
expect GCC will do the obvious thing: optimize it.

-- Gaby

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]