"Guido van Rossum" <[EMAIL PROTECTED]> 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.
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.)
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.
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.
Hope this helps.
Ian
