This is the mail archive of the gcc@gcc.gnu.org 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


Jack Howarth wrote:
import sys
divmod(-sys.maxint-1, -1)
(0, -2147483648)

If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...
(2147483648L, 0L)

So your analysis appears to be correct. Even more interesting is
that if I build python 2.4.3 with Apple's gcc from Xcode 2.3, the
correct results are obtained without the need to resort to the
-fwrapv flag. So either we have a regression in gcc trunk or Apple has a patch in their branch which was never moved over
It *is* a bug in python, here is the proof:
https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/Objects/intobject.c?revision=25647&view=markup
Function

* i_divmod*(*register* *long* x, *register* *long* y,

the following lines:

/        /* (-sys.maxint-1)/-1 is the only overflow case. *//
	*if* (y == -1 && x < 0 && x == -x)
		*return* DIVMOD_OVERFLOW;

If overflow is barred then x==-x may happen only when x==0.
This conflicts with x<0, which means that the compiler may assume
that
  x<0 && x==-x
always yields false. This may allow the compiler to eliminate the whole if
statement. Hence, clearly python is at fault.

Michael


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