[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Mark Dickinson]

Mark Dickinson  added the comment:

> This should probably be a separate issue,

Specifically, issue 45569.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.5, Python 
3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Mark Dickinson]

Mark Dickinson  added the comment:

This should probably be a separate issue, but I wonder whether the 15-bit digit 
option has value any more. Should we just drop that option and always use 
30-bit digits? 

30-bit digits were introduced at a time when we couldn't rely on a 64-bit 
integer type always being available,  so we still needed to keep the 15-bit 
fallback option. But I think that's no longer the case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Beier Liu]

Change by Beier Liu :


--
keywords: +patch
nosy: +Beier Liu
nosy_count: 7.0 -> 8.0
pull_requests: +27362
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/19326

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Stefan Behnel]

Stefan Behnel  added the comment:

The relevant macro seems to be "__MINGW64__". I have neither a Windows 
environment nor MinGW-64 for testing, but the logic should be the same as for 
the "_WIN64" macro, i.e.

#if defined(_WIN64) || defined(__MINGW64__)
#define MS_WIN64
#endif

And then there's probably also something to do to record the compiler version 
in the long CPython version string, etc. I also can't say if MinGW-64 sets the 
"MS_WIN32" macro. Having "MS_WIN64" without "MS_WIN32" might be unexpected for 
some code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Steve Dower]

Steve Dower  added the comment:

That variable should be inferred somewhere, either in PC/pyconfig.h or 
pyport.h. If there's a way to also infer it on 64-bit MinGW then we would 
consider a patch for that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Stefan Behnel]

Stefan Behnel  added the comment:

> There's PyLong_GetInfo ...

Thanks, I understand that this information can be found at runtime. However, in 
order to correctly compile C code against a given CPython runtime, there needs 
to be a guarantee that extension module builds use the same configuration as 
the CPython build.

> Misconfiguration

I searched some more, and it looks like this was already reported almost ten 
years ago in issue4709.

The work-around there is to pass -DMS_WIN64, which apparently is not defined by 
MinGW but required by the CPython headers.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

At runtime this information is available as sys.int_info.bits_per_digit.

> In MinGW, "SIZEOF_VOID_P" is 4, whereas "sizeof(void*)" resolves to 8.

Looks like a misconfiguration. I suppose this will cause more issues than just 
wrong PYLONG_BITS_IN_DIGIT.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Mark Dickinson]

Mark Dickinson  added the comment:

> Is there a reason why CPython cannot store its compile time value for the 
> PYLONG_BITS_IN_DIGIT setting somewhere?

There's PyLong_GetInfo [1], and at Python level, the corresponding 
sys.long_info (Python 2) / sys.int_info (Python 3). Does that help?





[1] 
https://github.com/python/cpython/blob/b2e2025941f6a4fdb716bd141d31acf720353d21/Objects/longobject.c#L5578-L5595

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Stefan Behnel]

Stefan Behnel  added the comment:

Some more information. CPython uses this code snippet to decide on the PyLong 
digit size:

#ifndef PYLONG_BITS_IN_DIGIT
#if SIZEOF_VOID_P >= 8
#define PYLONG_BITS_IN_DIGIT 30
#else
#define PYLONG_BITS_IN_DIGIT 15
#endif
#endif

In MinGW, "SIZEOF_VOID_P" is 4, whereas "sizeof(void*)" resolves to 8.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35037] PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC

[Stefan Behnel]

New submission from Stefan Behnel :

I see reports from Cython users on Windows-64 that extension modules that use 
"longintrepr.h" get miscompiled by MinGW. A failing setup looks as follows:

Stock 64 bit CPython on Windows, e.g.
Python 3.6.3 (v3.6.3:2c5fed8, Oct  3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)]

MinGW uses this compile time setup, i.e. 15 bit digits:
PyLong_BASE  0x8000
PyLong_MASK  7FFF
PyLong_SHIFT  15
sizeof(digit)  2
sizeof(sdigit)  2

Whereas CPython reports the following, indicating that it was in fact built 
with 30 bit digits:
sys.getsize(1, 2**14, 2**15, 2**29, 2**30, 2**63, 2**64)  (28, 28, 28, 28, 32, 
36, 36)

I'm not sure if this also applies to Py2.7, but I don't think the PyLong 
implementations differ in this regard.

The compile time PyLong digit size is not remembered by the CPython 
installation and instead determined on the fly by the extension compiler. It 
seems that the MSVC build of the stock CPython packages differs from what MinGW 
decides here. This renders MinGW unusable for code that uses "longintrepr.h", 
which Cython does by default in order to accelerate its unpacking of PyLong 
values.

Is there a reason why CPython cannot store its compile time value for the 
PYLONG_BITS_IN_DIGIT setting somewhere?

--
components: Extension Modules, Windows
messages: 328197
nosy: paul.moore, scoder, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PYLONG_BITS_IN_DIGIT differs between MinGW and MSVC
type: compile error
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com