This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc trunk vs python
On 27 Aug 2006 09:05:47 -0700, Ian Lance Taylor <iant@google.com> wrote:
"Guido van Rossum" <guido@python.org> writes:
> I know I cannot win an argument with the GCC developers but I can't
> help wondering if they've gone bonkers. They may get Python 2.5 fixed,
> but what about 2.4? 2.3? This code has been there for a long time.
>
> It would be better if one had to explicitly request this behavior,
> rather than explicitly disable it.
I hope I am not tediously stating the obvious when I say that this
general issue is not new to the gcc developers; even the accusation
that we have gone bonkers is seen with some regularity.
I understand. I get the same with Python on a regular basis.
The gcc developers always face two competing constituencies: do not
change the compiler behaviour so that existing code which relies on
undefined behaviour continues to work, and do change the compiler
behaviour so that new code which does not rely on undefined behaviour
runs faster. In general, being compiler developers, we come down on
the side of making code which does not rely on undefined behaviour run
faster.
Adding a new option to explicitly request new behaviour does not work
in practice. Very few people will know about it, so they will not use
it, so their code will continue to not run faster. (And, annoyingly
to us, they will continue to complain that gcc is a poor optimizer
compared to the competition, a widely-known and widely-repeated piece
of information which is actually false.)
I have not received reports about bugs in the offending code when
compiled with other compilers. I do note that Python in general
doesn't get much value out of compiler optimizations because the code
is not very regular -- there aren't too many recognizable loops that a
compiler can speed up.
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?
So since the amount of code that relies on signed overflow is very
small, and since the fix for that code is very simple, and since there
is a command line option to request the old behaviour, and since this
change lets us do significantly better optimization for real existing
code, I think this is a reasonable change to the compiler.
Further, as Daniel pointed out, gcc's behaviour on this code is
consistent with the behaviour of other optimizing compilers. So while
I don't know how often people compile Python code with anything other
than gcc, in some sense the Python code is (presumably) already broken
for those people.
Obviously all the above is only my view, but I think it is not
inconsistent with the view of most gcc developers.
While you are probably correct that you can not win an argument with
the gcc developers, I believe that most of us are open to reasonable
compromise. Requiring a new option to explicitly request this change
is not, to us, a reasonable compromise. But if you or anybody have
any other suggestions, we will certainly listen.
This gives me very few options. But I wonder if all overflow behavior
necessarily should be treated the same way. If GCC did not presume
that (x == -x) necessarily meant (x == 0) but instead assumed that x
could be either zero or 2**-(N-1), Python would not have a bug.
Hope this helps.
It has calmed me down. But I hope that the future quality of the
arguments defending the feature is better than Michael Veksler's
attempt. Thanks for responding in person.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)