On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
...
I have not received reports about bugs in the offending code when
compiled with other compilers.
I do know at least one another compiler that does this,
and at least one significant project (which is actually quite a bit
larger than Py
Guido van Rossum wrote:
It has calmed me down. But I hope that the future quality of the
arguments defending the feature is better than Michael Veksler's
attempt. Thanks for responding in person.
Sorry, next time I'll find a better example. Gosh, who would think
that a benign example, would st
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
[...]
| > In general I think I personally am on the very conservative edge of
| > gcc developers, in that I am generally opposed to breaking existing
| > code. But this particular optimization will let us do a much better
| > job on very simple loop
On 27 Aug 2006 09:05:47 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I know I cannot win an argument with the GCC developers but I can't
> help wondering if they've gone bonkers. They may get Python 2.5 fixed,
> but what about 2.4? 2.3? This
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I know I cannot win an argument with the GCC developers but I can't
> help wondering if they've gone bonkers. They may get Python 2.5 fixed,
> but what about 2.4? 2.3? This code has been there for a long time.
>
> It would be better if one had to e
On 8/26/06, Michael Veksler <[EMAIL PROTECTED]> wrote:
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?
>
> http://mail.python.org/pipermail/python-dev/2006-August/068482.html
>
>
*Guido van Rossum wrot
Michael Veksler wrote:
First, you can always use -fwarpv and retail old behavior. Any code that
^^
-fwrapv
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?
http://mail.python.org/pipermail/python-dev/2006-August/068482.html
*Guido van Rossum wrote:
*
I'm not sure I follow why this isn't considered a regre
Would any of the gcc developers care to drop by the python-dev
mailing list and give the author of python an answer?
http://mail.python.org/pipermail/python-dev/2006-August/068482.html
On 8/26/06, Jack Howarth wrote:
>
Paolo Bonzini wrote:
Jack Howarth wrote:
+ if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x)
return DIVMOD_OVERFLOW;
or just a much clearer
if (y == -1 && x == INT_MIN)
return DIVMOD_OVERFLOW;
(possibly with a #include at the top).
Nit picking -
"x" i
Jack Howarth wrote:
Andrew,
Thanks. The change...
--- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0
-0400
+++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400
@@ -479,7 +479,7 @@
return DIVMOD_ERROR;
}
/* (-s
Andrew,
Thanks. The change...
--- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0
-0400
+++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400
@@ -479,7 +479,7 @@
return DIVMOD_ERROR;
}
/* (-sys.maxint-1)/-1 is the
x < 0 && x == -x
That is the issue right there really, doing x == -x will never be true
because -x will overflow for INT_MIN.
Doing "((unsigned)x) == -(unsigned)x" should fix the issue.
Note this is unrelated to Darwin or any processor really too.
-- Pinski
Michael,
I submitted a bug report to the python developers. Do you
have a suggestion on how...
/* (-sys.maxint-1)/-1 is the only overflow case. */
if (y == -1 && x < 0 && x == -x)
return DIVMOD_OVERFLOW;
...should be reworked? Since I am tickling the bug at the
Sorry for the formatting weirdness. I should be more careful with
Thunderbird's auto-conversion to plain text. Here is the correct
version:
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...
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 fro
On Aug 23, 2006, at 3:27 PM, Jack Howarth wrote:
The only difference I can see between the builds with gcc trunk and
Apple's gcc is that I have to remove the -Wno-long-double -no-cpp-
precomp flags the build with gcc trunk (because they don't exist).
My only comment would be to remove -Wno-lo
> 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
Michael,
If I build python 2.4.3 with the default compiler flags under gcc trunk
on MacOS X 10.4.7, I get the following...
Python 2.4.3 (#1, Aug 23 2006, 17:39:08)
[GCC 4.2.0 20060822 (experimental)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import s
Hello Jack,
I has been almost a week since you mailed your question. I hope my
answer is still relevant.
Jack Howarth wrote:
Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2
seems to introduce a new regression in the Python testsuite...
test_builtin
test test_bu
Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2
seems to introduce a new regression in the Python testsuite...
test_builtin
test test_builtin failed -- Traceback (most recent call last):
File "/Users/howarth/Python-2.4.3/Lib/test/test_builtin.py", line 233, in
tes
21 matches
Mail list logo
