Yury V. Zaytsev added the comment:
Well, the machine that I had the problem on does no longer exist and I'm not
sure whether this is a generic POWER issue.
The problem was that I had to cross-compile Python on one generation of POWER
machines for another POWER chip using its own special
Yury V. Zaytsev added the comment:
Another scenario how this could happen is when Python interpreter is run from a
scheduled job on a BlueGene/Q node by the CNK; this is a minimalist execution
environment where getpwuid() is unable to resolve home directories for UIDs
running the jobs
New submission from Yury V. Zaytsev:
Hi,
I've managed to get the test suite of Python to run on Python 3.4.0b2 version
cross-compiled for a specialized POWER chip. I get a number of failures that
seem to have the same nature. I'm under impression, that actually the tests
might need
Yury V. Zaytsev added the comment:
The CPU model is IBM PowerPC A2, the information about the cross-compiler is as
follows:
$ /bgsys/drivers/ppcfloor/gnu-linux/bin/powerpc64-bgq-linux-gcc -v
Reading specs from
/bgsys/drivers/toolchain/V1R2M1_base/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.6
Changes by Yury V. Zaytsev y...@shurup.com:
Added file: http://bugs.python.org/file33613/pyconfig.h
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20342
Yury V. Zaytsev added the comment:
I've re-named the issue to reflect the problem.
One possible solution that I can see is to use AC_C_BIGENDIAN macro, either
exclusively, or only when cross-compiling.
In the latest autoconf sources, this macro seems to try to detect the
endianness from
New submission from Yury V. Zaytsev:
Hi,
When I try the following:
./python -m test -v test_hash
on a self-compiled Python 3.4.0b2 on RHEL 6.5 / ppc64, it fails. Please let me
know which additional information I can supply to diagnose the problem.
The complete traceback below
Yury V. Zaytsev added the comment:
As requested by Victor Stinner:
./python -c 'import sys; print(sys.hash_info)'
sys.hash_info(width=64, modulus=2305843009213693951, inf=314159, nan=0,
imag=103, algorithm='siphash24', hash_bits=64, seed_bits=128, cutoff=0)
--
components
Yury V. Zaytsev added the comment:
Sorry for accidentally rolling back your changes to the bug, Antoine!
--
components: +Interpreter Core -Tests
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20162
Changes by Yury V. Zaytsev y...@shurup.com:
--
components: +Tests
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20162
___
___
Python-bugs-list
Yury V. Zaytsev added the comment:
==
FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase)
(prefix='abc')
--
Traceback (most recent call last
Yury V. Zaytsev added the comment:
To check whether the problem is in the _le64toh() macro as suggested by Victor
Stinner, I've tried the attached patch and the problem is gone.
As it turns out, there actually seem to be two problems:
First, HAVE_ENDIAN_H is properly defined, because
Yury V. Zaytsev added the comment:
I was also asked to mention this:
https://github.com/majek/csiphash/blob/master/csiphash.c
as an alternative implementation of siphash and platform checks.
--
___
Python tracker rep...@bugs.python.org
http
Yury V. Zaytsev added the comment:
After lots of fiddling, I can tell you what's wrong with the macro: apparently
it's a compiler bug, visible at -O2 and disappearing at -O1.
Assembly output is attached, unfortunately, I'm no ppc64 expert, so I can't
immediately tell what exactly went wrong
Yury V. Zaytsev added the comment:
Amusingly, it's also the case on BG/Q compute nodes. Only this morning, I
cooked up the following patch:
--- a/Lib/posixpath.py
+++ b/Lib/posixpath.py
@@ -237,7 +237,11 @@ def expanduser(path):
if i == 1:
if 'HOME' not in os.environ
Yury V. Zaytsev added the comment:
Hi David,
It's gcc from RHEL 6.5 gcc-4.4.7-4.el6.ppc64, the flags are -DNDEBUG -g
-fwrapv -O2 -Wall -Wstrict-prototypes vs. -DNDEBUG -g -fwrapv -O1 -Wall
-Wstrict-prototypes.
The problem is, I can't isolate it. We honestly tried it with Victor, but gcc
Yury V. Zaytsev added the comment:
Look for _le64toh ;-)
--
Added file: http://bugs.python.org/file33347/pyhash.preproc.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20162
Yury V. Zaytsev added the comment:
Digging more into it, I guess I know why we couldn't come up with a minimal
reproducer for this problem. If I compile with -O2 instead of -O1, I get the
following warning from gcc:
Python/pyhash.c:413: warning: dereferencing pointer 'pt.32' does break
Changes by Yury V. Zaytsev y...@shurup.com:
--
nosy: +zaytsev
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10496
___
___
Python-bugs-list mailing
Yury V. Zaytsev added the comment:
Related issue where memcpy() was discussed: http://bugs.python.org/issue19183 .
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20162
Yury V. Zaytsev added the comment:
Hi Christian,
Dave says it's not a compiler bug; the code is slightly violating the C
standard, and the compiler optimizes based on a strict reading of the rules.
If I compile with -O2 and higher (while -O3 is the default for Python, as far
as I can
New submission from Yury V. Zaytsev:
PEP-3149 (issue9193) introduces new variables (SO and SOABI) so that one can
find out what are the supported extension suffixes.
Quote from the PEP:
sysconfig.get_config_var('SO')
'.cpython-32mu.so'
sysconfig.get_config_var('SOABI')
'cpython-32mu'
Later
Yury V. Zaytsev added the comment:
Hi Raymond,
This is a brilliant idea, but before it hits the streets, couldn't you possibly
consider extending it with a kwarg to control the depth of the exception stack?
The use case I have for that are snippets like this:
with ignored(ValueError
Yury V. Zaytsev added the comment:
Actually, please disregard my idea. It's way to dangerous, especially in the
case of multiple exceptions to ignore :-(
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15806
Yury V. Zaytsev added the comment:
Hi,
I agree with Alexander, I've been recently investigating a related problem and
I found the lack of documentation on the subject quite frustrating; I therefore
propose the attached patch to the docs.
Hope that helps,
--Yury.
--
keywords: +patch
Yury V. Zaytsev added the comment:
NumPy no longer uses the Trac for issues, the tracking has been moved to
GitHub. I hope that the problem will be finally solved in NumPy by
https://github.com/numpy/numpy/pull/3526 .
--
nosy: +zaytsev
___
Python
Yury V. Zaytsev added the comment:
As noted in issue5476, I've submitted a pull request for NumPy:
ttps://github.com/numpy/numpy/pull/3526 .
I hope that this fixes this problem too: on Py2, I've added
Py_TPFLAGS_INT_SUBCLASS, on Py3, NumPy doesn't inherit from int anymore,
because it's
New submission from Yury V. Zaytsev:
Hi,
The links to NumPy sites and documentation are outdated. I replaced them with
www.numpy.org, and also the canonical location for documentation
(docs.scipy.org).
I removed the explicit mention of the PDF file, because the documentation has
been split
28 matches
Mail list logo
