Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset b378864d8ff3 by Mark Dickinson in branch '3.2':
Issue #12973: Fix itertools bug caused by signed integer overflow. Thanks
Stefan Krah.
http://hg.python.org/cpython/rev/b378864d8ff3
New changeset 18eec56bcf29 by
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 5a1cb8506cea by Mark Dickinson in branch '2.7':
Backport issue #12973 itertools fix from 3.x.
http://hg.python.org/cpython/rev/5a1cb8506cea
--
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
Okay, all fixed here. Let's add any further signed overflow issues to the
issue #1621 discussion.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 07efe83795b0 by Mark Dickinson in branch '2.7':
Issue #12973: Fix int.__pow__ overflow checks that invoked undefined behaviour,
thereby producing incorrect results on Clang.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 99b808c94834 by Mark Dickinson in branch '3.2':
Issue #12973: Fix undefined-behaviour-inducing overflow check in list_repeat.
http://hg.python.org/cpython/rev/99b808c94834
New changeset 2dbd5870de0b by Mark
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset f8280cf63d9e by Mark Dickinson in branch '2.7':
Backport issue #12973 list_repeat fix from 3.x.
http://hg.python.org/cpython/rev/f8280cf63d9e
--
___
Python tracker
Changes by Terry J. Reedy tjre...@udel.edu:
--
resolution: duplicate -
stage: committed/rejected - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12973
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file23164/listobject_overflow.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12973
___
Changes by Stefan Krah stefan-use...@bytereef.org:
Added file: http://bugs.python.org/file23165/itertools_overflow.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12973
___
Stefan Krah stefan-use...@bytereef.org added the comment:
With issue12975.diff, listobject_overflow.diff and itertools_overflow.diff
I don't get any more failures.
Also, of course issue12975.diff looks correct to me if we assume:
Mark Dickinson dicki...@gmail.com added the comment:
Gah; did I really misnumber that issue patch? Sorry.
Mark, did you write those rules down somewhere?
Well, they're all in the standard, which is publicly available. (Or at least,
a draft of the standard that's pretty much
Mark Dickinson dicki...@gmail.com added the comment:
an assumption that the C implementation will never raise an
'implementation-defined' signal (C99 6.3.1.3p3).
Sorry, this should have been more explicit: will never raise ... when
converting long to unsigned long
--
Mark Dickinson dicki...@gmail.com added the comment:
Those two patches (for listobject and itertools) look fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12973
___
Stefan Krah stefan-use...@bytereef.org added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
Well, they're all in the standard, which is publicly available.
I have the real thing. :)
The correctness of the patch depends on:
(2) an assumption that the C implementation will never
Mark Dickinson dicki...@gmail.com added the comment:
Reopening and assigning to me; it would be good to fix this in intobject.c as
well as adding the Clang-specific -fwrapv fix.
--
assignee: - mark.dickinson
nosy: +mark.dickinson
status: closed - open
Martin v. Löwis mar...@v.loewis.de added the comment:
Notice that this signed overflow issue is also tracked as #1621. I don't mind
keeping this issue open, though - it's unlikely that #1621 will be fixed within
this decade. unless somebody does some heroic effort.
--
nosy: +loewis
Mark Dickinson dicki...@gmail.com added the comment:
Here's a simple patch. Is anyone in a good position to see if this fixes the
tests failures for Clang (without the fwrapv flag)?
--
keywords: +patch
Added file: http://bugs.python.org/file23155/issue12975.diff
STINNER Victor victor.stin...@haypocalc.com added the comment:
I removed -fwrapv from configure and Makefile, but I'm unable to reproduce the
issue with clang 2.8 on x86_64 (Fedora 15).
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Thanks Victor; I just managed to install Clang, and it looks I can reproduce
the failures. I'm testing right now to see if the patch fixes them all...
--
___
Python tracker rep...@bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
Thanks Victor; I just managed to install Clang,
and it looks I can reproduce the failures.
What is your clang version? I ran ./python -m test -v test_long to check the
issue.
--
___
Mark Dickinson dicki...@gmail.com added the comment:
I've got Clang from MacPorts, on OS X 10.6.8.
iwasawa:cpython mdickinson$ clang --version
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix
Without the patch (and before the -fwrapv inclusion), I get
STINNER Victor victor.stin...@haypocalc.com added the comment:
Aaaah, int_pow. I was testing Python 3.3.
I tested Python 2.7 with clang 2.8, optimization level at -03 and without
-fwrapv... I'm still unable to reproduce the issue. It's maybe an optimization
introduced by clang 2.9.
--
This
Stefan Krah stefan-use...@bytereef.org added the comment:
== CPython 2.7.2+ (2.7:a698ad2741da+, Sep 15 2011, 00:17:28) [GCC 4.2.1
Compatible Clang 3.0 (trunk 139637)]
== FreeBSD-8.0-RELEASE-amd64-64bit-ELF little-endian
== /usr/home/stefan/pydev/cpython/build/test_python_71451
With clang
New submission from Adam a...@netbsd.org:
int_pow() (from Objects/intobject.c) shows incorrect results when Python is
compiled with Clang (llvm.org); long story short: int_pow() function should use
'unsigned long' type instead of 'long' or some code gets optimised out.
Please, refer to this
Stefan Krah stefan-use...@bytereef.org added the comment:
I think this is related to issue #11149. Can you try compiling with
-fwrapv?
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12973
Stefan Krah stefan-use...@bytereef.org added the comment:
I can reproduce your results with a recent clang. gcc has similar
optimization behavior, but for gcc ./configure automatically adds
-fwrapv, which prevents the incorrect results.
I'm closing this as a duplicate of #11149.
--
26 matches
Mail list logo
