This is the mail archive of the
mailing list for the GCC project.
Re: gcc trunk vs python
- From: Michael Veksler <mveksler at techunix dot technion dot ac dot il>
- To: Jack Howarth <howarth at bromo dot msbb dot uc dot edu>
- Cc: mveksler at techunix dot technion dot ac dot il, gcc at gcc dot gnu dot org, geoffk at apple dot com, mrs at apple dot com
- Date: Thu, 24 Aug 2006 04:41:13 +0300
- Subject: Re: gcc trunk vs python
- References: <20060823222747.23EEE11000E@bromo.msbb.uc.edu>
Jack Howarth wrote:
If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...
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:
* 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)
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
x<0 && x==-x
always yields false. This may allow the compiler to eliminate the whole if
statement. Hence, clearly python is at fault.