Hi Logan,
I wanted to start by stressing that this is really impressive progress.
We've never had get so far with a new backend without serious support by
the core JIT devs, so thanks a lot for your work, I'm really excited
about this!
A general suggestion about the test failures: for the failing tests it's
worth it to see whether they also fail when you pass
--jit off
To the pypy binary. If they fail the same way, you can rule out your
backend as the cause of the failure.
I put comments about specific cases inline below.
On 1/29/24 04:26, Logan Chien wrote:
Hi,
I have one question regarding
pypy/module/_rawffi/alt/test/test_funcptr.py. In test_getaddressindll,
the test uses `sys.maxint*2 - 1` as the mask (on linux):
def test_getaddressindll(self):
import sys
from _rawffi.alt import CDLL
libm = CDLL(self.libm_name)
pow_addr = libm.getaddressindll('pow')
fff = sys.maxint*2-1 ### WHY??
if sys.platform == 'win32' or sys.platform == 'darwin':
fff = sys.maxint*2+1
assert pow_addr == self.pow_addr & fff
But on Linux (both x86_64 and riscv), `sys.maxint*2 - 1` is
0xffffffff_fffffffd (or 0b1111_...._1111_1101). Why does the mask end
with 0xd? It is a little weird because if the intention is to ensure
the address is aligned to multiple of 4, the mask should end with 0xc.
It is causing a problem for the RISC-V backend because in RISC-V the
function address can be multiple of 2.
This test looks just wrong, in my opinion. Given that the variable name
is `fff`, I think it was just meant as a check "does it roughly look
like a pointer". So I think somebody just forgot that sys.maxint is not
a power of 2 (and then things failed on win32 and darwin and somebody
fixed it with the extra if). You can change the test to always use
sys.maxint*2+1.
# Other status updates
This week I ran the test suites (see results below). I fixed one error
related to large frame slot offsets (caught by test_tarfile).
* Test Suite: app-level (-A) test
* test_getsetsockopt_zero -- It looks like a buffer uninitialized
error (the second byte changes between runs) (untriaged)
* test_half_conversions -- No idea (untriaged)
* test_floorceiltrunc -- It looks like RISC-V floor/ceil/trunc don't
preserve signbit for nan inputs.
* test__mercurial -- It looks like I have to install git and rebuild
a pypy from scratch.
* Test Suite: -D tests
* All passes.
* Test Suite: extra tests
* test_connection_del - OperationalError: Could not open database
(untriaged)
* Test Suite: lib-python test
* test_ssl -- (untriaged)
* test_tokenize -- (untriaged)
* test_zipfile64 -- It looks like heap corruption (maybe related to
bad malloc_nursery fast path) (untriaged)
* Test Suite: pypyjit tests
* test_jitlogparser -- (untriaged)
* test_micronumpy -- (untriaged)
I also ran test_ll_random.py with `--repeat=20000 --random-seed=1234`
and all test are passing.
How long does that take, in wall clock time? I think for the other
backends we kept it running for a bunch of days after the last crash
occurred.
Cheers,
CF
_______________________________________________
pypy-dev mailing list -- pypy-dev@python.org
To unsubscribe send an email to pypy-dev-le...@python.org
https://mail.python.org/mailman3/lists/pypy-dev.python.org/
Member address: arch...@mail-archive.com
