OK, I reworked (and attached) the patch for the suggestions to nt_threads.[ch]. You had no comments for dtoa.c.
This is great. From inspection, there doesn't seem to be any other changes needed to the C code in rpython/translator/c for Windows 64 support. I am assuming the 'gcc' folder there does not matter. 1. Are there any other directories where C code needs to be reviewed to support Windows 64? 2. That still leaves the rpython code in rpython/translator/c. Can you show an example of where that needs fixing (regarding sizeof(long)) so I can use that as a pattern for the remaining code? 3. rpython/jit/backend/x86: it's still not clear what part needed work here Thanks, -Roger ________________________________ From: Amaury Forgeot d'Arc <amaur...@gmail.com> To: Maciej Fijalkowski <fij...@gmail.com> Cc: PyPy Developer Mailing List <pypy-dev@python.org> Sent: Thursday, April 11, 2013 3:23 AM Subject: Re: [pypy-dev] Fwd: Windows 64 bit version 2013/4/11 Maciej Fijalkowski <fij...@gmail.com> windows 64 patches that I got, can someone have a look? This patch won't have any effect - linuxmemchk is not used on windows. - the changes in obmalloc, stack.c, stacklet.c are not necessary, differences between stack addresses won't overflow 32bit. - in thread_nt.c, RPyThreadSetStackSize should take a long, or maybe an unsigned (_beginthread takes an unsigned) - in thread_nt.c, _beginthread returns uintptr_t, so maybe rv should be changed to this type; -- Amaury Forgeot d'Arc _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
ptr_diff2
Description: Binary data
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
