<mattip>
of course it only happens on avx512 hardware (11th generation intel ) so it will take me a while to replicate locally
Julian has quit [Ping timeout: 265 seconds]
Julian has joined #pypy
<mattip>
arigato: any other ideas what might be off with the JIT and registers on win64 ?
<arigato>
Looking, I seem to remember some issue but it doesn't really make sense to me so far
<mattip>
there is this sentence "Consider volatile registers destroyed on function calls unless otherwise safety-provable by analysis such as whole program optimization."
<mattip>
and I NumPy uses the /LTCG flag for linking
<mattip>
which comes from the pypy/3/lib-python distutils, if not overridden by setuptools
otisolsen70 has quit [Quit: Leaving]
gef has quit [Ping timeout: 272 seconds]
gef has joined #pypy
<mattip>
back to jit/backend/llsupport/codemap.py, the reason it fails on win64 is that it uses Signed in python but long in C
<mattip>
so the INT_LIST_PTR does not work
<mattip>
but I think win64 does not use codemap anyway
<mattip>
so what would be better: skip the test or change lltype.Signed to rffi.LONG in codemap.py ?
<mattip>
arigato ^^^
gef has quit [Write error: Connection reset by peer]
<smarr>
I have `-O1` and `-O2` compilations segfault on me, `-O0 --no-gcremovetypeptr --gc=minimark` doesn't segfault. What's the best way to debug this? Especially with access to the source code so that I can avoid doing everything in assembly
<smarr>
I have some issues with RPython seemingly constant folding something to `NULL`, which shouldn't be `NULL` and works fine when executing normally.
<smarr>
The specific code looks something like this:
<smarr>
```
<smarr>
def get_class(self, universe):
<smarr>
return universe.array_class
<smarr>
```
<smarr>
return universe.array_layout
<smarr>
def get_object_layout(self, universe):
<smarr>
`get_class` compiles correctly to a read
<smarr>
but `get_object_layout` doesn't compile to a read. It compiles to simply returning `NULL`. both fields are marked as named in `_immutable_fields_` to be immutable
<smarr>
this is all very mysterious. the same code compiles to a proper read when I compiler the interpreter with my AST instead of my bytecode interpreter.