Jack Howarth wrote:

Guido, You'll never win that argument with the gcc developers. If you rely on undefined behavior in the c language standard, they have in the past, and will continue to, feel free to ignore those cases. If you plan on ignoring this issue, just be prepared to see a testcase failure in the python testsuite when python is built with gcc 4.2.

In addition, i'm surprised that you don't see these failures on other compilers. I know XLC, for example, would treat signed integer overflow as undefined at all opt levels as well. I would not be surprised to find Intel's compiler doing the same thing. Speaking as a gcc optimization person, if we were to treat signed integer overflow as wrapping, you would inhibit a very large number of loop optimizations on a very large class of loops (due to a number of reasons, from no longer being able to prove termination of loops or estimation of number of iterations, to other things). Heck, XLC at -O3+ will ignore *unsigned* integer wraparound of loop indices unless you use -qstrict_induction. As the docs for this option say, using that option can cause severe performance degradation (I happen to know the numbers from when i worked at IBM, and they are surprisingly high). GCC is willing to take the performance hit relative to other compilers on things like that to be a standard conforming compiler, just like we are willing to optimize code based on the assumption that you do not invoke undefined behavior. --Dan