Re: [Python-Dev] Removing anachronisms from logging module

[A.M. Kuchling]

On Fri, Aug 25, 2006 at 10:44:53AM -0700, Guido van Rossum wrote:
> any more; neither does Vinay. I propose as a project for someone to
> clean it up ...

There's a list of simple tasks in the wiki at
.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] gcc 4.2 exposes signed integer overflows

[Jack Howarth]

   I discovered that gcc 4.2 exposes a flaw with
signed integer overflows in python. This bug and the
necessary fix has been discussed in detail on the gcc
mailing list. I have filed a detailed bug report and
the recommended patch proposed by the gcc developers.
This problem should be addressed BEFORE python 2.5 is
released. The bug report is...

[ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows

in the python sourceforge bug tracker. Thanks in advance
for attempting to fix this before Python 2.5 is released.
 Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Guido van Rossum]

On 8/26/06, Jack Howarth <[EMAIL PROTECTED]> wrote:
>I discovered that gcc 4.2 exposes a flaw with
> signed integer overflows in python. This bug and the
> necessary fix has been discussed in detail on the gcc
> mailing list. I have filed a detailed bug report and
> the recommended patch proposed by the gcc developers.
> This problem should be addressed BEFORE python 2.5 is
> released. The bug report is...
>
> [ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows
>
> in the python sourceforge bug tracker. Thanks in advance
> for attempting to fix this before Python 2.5 is released.

I'm not sure I follow why this isn't considered a regression in GCC.
Clearly, on all current hardware, x == -x is also true for the most
negative int (0x8000 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...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Jack Howarth]

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.
Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[David Hopwood]

Guido van Rossum wrote:
> On 8/26/06, Jack Howarth <[EMAIL PROTECTED]> wrote:
> 
>>   I discovered that gcc 4.2 exposes a flaw with
>>signed integer overflows in python. This bug and the
>>necessary fix has been discussed in detail on the gcc
>>mailing list. I have filed a detailed bug report and
>>the recommended patch proposed by the gcc developers.
>>This problem should be addressed BEFORE python 2.5 is
>>released. The bug report is...
>>
>>[ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows
>>
>>in the python sourceforge bug tracker. Thanks in advance
>>for attempting to fix this before Python 2.5 is released.
> 
> I'm not sure I follow why this isn't considered a regression in GCC.
> Clearly, on all current hardware, x == -x is also true for the most
> negative int (0x8000 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...

+1. It's clearly undefined behaviour, but that doesn't mean that it is a
good idea for gcc to be making changes that could silently break a lot of
code, in pursuit of a microoptimization that is unlikely to significantly
help performance.

CPython should be fixed anyway. The correct fix is
"if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".

-- 
David Hopwood <[EMAIL PROTECTED]>


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Thomas Wouters]

On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
CPython should be fixed anyway. The correct fix is"if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".Why not just "... && x == LONG_MIN"?
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Daniel Berlin]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Tim Peters]

[David Hopwood]
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".

Note that this was already suggested in the bug report.

[Thomas Wouters]
> Why not just "... && x == LONG_MIN"?

In full,

if (y == -1 && x == LONG_MIN)

"should work" too.  In practice we try to avoid numeric symbols from
platform header files because so many platforms have screwed these up
over the centuries (search for LONG_BIT or HUGE_VAL ;-)), and because
it's better (when possible) not to tie the code to that `x` was
specifically declared as type "long" (e.g., just more stuff that will
break if Python decides to make its short int of type PY_LONG_LONG
instead).  In this specific case, there may also have been a desire to
avoid generating a memory load for a fat constant.  However, since
this is integer division, in real life (outside the test suite) we'll
never go beyond the "y == -1" test.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[David Hopwood]

Thomas Wouters wrote:
> On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
> 
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
> 
> Why not just "... && x == LONG_MIN"?

Because the intent is to check that x / y does not overflow a long, and
x == LONG_MIN would not cause an overflow on 1's complement or sign-magnitude
systems.

(CPython has probably only been tested on 2's complement systems anyway,
but if we're going to be pedantic about depending only on things in the
C standard...)

-- 
David Hopwood <[EMAIL PROTECTED]>


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

[Tim Peters]

[David Hopwood]
> (CPython has probably only been tested on 2's complement systems anyway,

Definitely so.  Are there any boxes using 1's-comp or sign-magnitude
integers anymore?  Python assumes 2's-comp in many places.

> but if we're going to be pedantic about depending only on things in the
> C standard...)

No, in that respect we're driven by the silliest decisions made by C
compiler writers ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com