Hi Diana, Answering you on the pypy-dev mailing list. The question is about Win64 support (http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit...): On 19 September 2016 at 14:34, Popa, Diana <diana.popa@intel.com> wrote:

First of all, I started by translating PyPy on win64 with a hacked 2.7 Python as described in the provided URL. I am encountering a problem when trying to calculate MAX_DIGITS_THAT_CAN_FIT_IN_INT = rbigint.fromint(-sys.maxint - 1).numdigits(). (...)

The URL doesn't describe what you are doing: it tells about hacking Python 2.7, yes, but the next thing it says you should do is trying to pass a specific subset of the tests. There is no point in immediately trying to translating PyPy. But anyway, if you tried doing that, you would hit the same problem immediately. This is caused by the "precision loss" I wrote about on that page. I assume that sys.maxint is equal to 2**63-1 in your hacked Python. Then likely some operations occur in C on this "long long" value that temporarily cast the value to "long", resulting in precision loss. You have to track down what it is. For example, start by writing some tests and put them in rpython.rlib.test.test_win64: def test_basic_arithmetic(): def eq(x, y): assert type(x) is type(y) is int return x == y x = 2**50 assert eq(x, 2**50) assert str(x) == "1125899906842624" assert str(sys.maxint) == "9223372036854775807" assert eq(sys.maxint, int(2**63-1)) assert eq(x + x, 2**51) assert eq(x - (-x), 2**51) assert eq(x * 4, 2**52) assert eq(x | x, 2**50) assert eq(x >> 1, 2**49) etc. ...as I guess that there is code a bit everywhere that depends on that. Fixing such failures is a matter of tracking down where CPython stores things temporarily inside "long". It is not necessary to get a perfect CPython that handles "long long" systematically, but at least the basics like above should work. Alternatively, you could try to globally replace "long" with "long long" and similar. A bientôt, Armin.