Mark Dickinson dicki...@gmail.com added the comment:
Test fixed for 2.7, 3.1 in r71837, r71839
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5593
Mark Dickinson dicki...@gmail.com added the comment:
Hmm. I can't reproduce this.
Is this a failure that just started happening recently on this
particular platform, or is this the first time you ran the
math test with this setup? I can't see any recent checkins
that could have precipitated
Antoine Pitrou pit...@free.fr added the comment:
Yikes. I can't reproduce it anymore. Perhaps make distclean is really
necessary when switching a working copy from a 64-bit to a 32-bit
build... Sorry for the noise.
--
resolution: - invalid
status: open - closed
Mark Dickinson dicki...@gmail.com added the comment:
Sorry for the noise.
Not noise. I'd still be interested in understanding where this is coming
from; I seem to recall someone else having exactly the same experience
(reported bug, then found that it disappeared after a clean compile).
Mark Dickinson dicki...@gmail.com added the comment:
Found the other report of this: see issue 3421.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5593
___
Mark Dickinson dicki...@gmail.com added the comment:
My best guess is that you somehow ended up in a situation where the math
module was using the x87 FPU for floating-point, while the interpreter
core was using SSE2. Is this possible?
I should also have said that this would fit with the
Antoine Pitrou pit...@free.fr added the comment:
My best guess is that you somehow ended up in a situation where the math
module was using the x87 FPU for floating-point, while the interpreter
core was using SSE2. Is this possible?
That would be the reverse, since this occurred on a
Mark Dickinson dicki...@gmail.com added the comment:
Wouldn't it be a problem with stale pyc files then?
Hah! Yes! That seems entirely likely.
So what sequence of moves does one have to go through
to reproduce this?
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
Wouldn't it be a problem with stale pyc files then?
Hah! Yes! That seems entirely likely.
So what sequence of moves does one have to go through
to reproduce this?
I suppose: first run -m test.regrtest -v test_math in 64-bit mode,
then
Mark Dickinson dicki...@gmail.com added the comment:
Thanks, Antoine! Yes, I can now reproduce the testFsum failure on my
MacBook Pro (OS X 10.5.6/x86_64, with Apple's gcc 4.0.1) using the
following sequence of commands: (I tested this for the trunk, but I
py3k should be just the same).
Antoine Pitrou pit...@free.fr added the comment:
I think it would be sufficient to invoke the addition through a helper
function, that is:
def add(x, y):
return x + y
if add(1e16, 2.0) != add(1e16, 2.):
return
Also, instead of return, you might use the new raise
New submission from Antoine Pitrou pit...@free.fr:
I started getting this in release30-maint (not in py3k).
==
FAIL: testFsum (test.test_math.MathTests)
--
Antoine Pitrou pit...@free.fr added the comment:
It only seems to happen on a 32-bit build on a 64-bit system.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5593
___
Antoine Pitrou pit...@free.fr added the comment:
And it actually also happens in py3k (but only in 32-bit mode, too).
--
versions: +Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5593
14 matches
Mail list logo
