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: gcc at gcc dot gnu dot org, guido at python dot org
- Date: Sun, 27 Aug 2006 07:40:36 +0300
- Subject: Re: gcc trunk vs python
- References: <20060826222747.5FD6C110019@bromo.msbb.uc.edu>
Jack Howarth wrote:
Would any of the gcc developers care to drop by the python-dev
mailing list and give the author of python an answer?
*Guido van Rossum wrote:
I'm not sure I follow why this isn't considered a regression in GCC.First, you can always use -fwarpv and retail old behavior. Any code that
Clearly, on all current hardware, x == -x is also true for the most
negative int (0x80000000 on a 32-bit box). Why is GCC attempting to
break our code (and then blaming us for it!) by using the C standard's
weaselwords that signed integer overflow is undefined, despite that it
has had a traditional meaning on 2's complement hardware for many
decades? If GCC starts to enforce everything that the C standard says
is undefined then very few programs will still work...
or suspects breakage by the new behavior may use this flag.
Second, consider the following example:
Once upon a time
int *p; /* No init!!! */
if (*p && 0) *p=0;
would not crash (DOS days). One could say
"Why should Microsoft or Borland crash our code? Clearly, the
value of "p" should never be read or written".
This example broke when we had memory protection. Memory
protection is a good thing, right?
Similarly, the new gcc behavior allows for better optimization.
Also, we are told that some boxes, have different codes for signed
and unsigned operations, where signed overflows either trap
or saturate (IIRC on x86, MMX saturates on overflow)
Once I had a similar claim to yours (against this overflow behavior):
But after extensive searches, I could not find code that breaks due
to this new behavior of overflow. Such code is apparently rare.