-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
MAINT: Overhaul and refactor NPY_OS_WIN* #23806
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
An addendum to numpy#20884 that fixes and deobfuscates Windows OS defines. NPY_OS_WIN64 was never defined, as _WIN32 is defined whenever _WIN64 is. Rename NPY_OS_WIN* constants to be less ambiguous, to avoid future confusion about their meanings. Also remove NPY_OS_MINGW, since it too never got defined. Note that MINGW is not an OS anyway, but a build environment like MSVC. All changes either preserve functionality or restore original intent.
@cbrt64 iirc the stack alignment is helping to encourage the compiler to place things in the correct registers whilst also working around the compiler not wanting to index into them directly (we don't have TLDR; It should only need to inline on 32-bit windows |
So, the current main branch is broken? I am OK with changing the macros a bit, but it should have a release note. It is probably also too late for doing this for the next release. @cbrt64 can I convince you to make a minimal fixup to merge quickly? Sorry that I messed it up on the other PR. |
I can do that. I'm thinking just use |
The temporary code got a bit lost in hard to understand macros, see numpygh-23806. This applies the minimal suggested fix, which is already being shipped by msys2: msys2/MINGW-packages#16931 Co-authored-by: Edward E <[email protected]>
The temporary code got a bit lost in hard to understand macros, see numpygh-23806. This applies the minimal suggested fix, which is already being shipped by msys2: msys2/MINGW-packages#16931 Co-authored-by: Edward E <[email protected]>
Going to push this off to 2.2, but it looks like is needs a refresh in any case. Maybe close? |
Pushing off to 2.3. Is this still relevant? |
When #20884 added
NPY_OS_WIN64
, the meaning ofNPY_OS_WIN32
became ambiguous; some might take it to mean "32-bit only", while others might assume its original meaning of "any Windows".Besides that, the directives as written confuse the nature of
_WIN32
, which I understand to be always defined in any native Windows toolchain. Thus#define NPY_OS_WIN64
would never be reached.This commit disambiguates by removing
NPY_OS_WIN32
(in case anyone uses it in future without looking again at its definition), and addingNPY_OS_WINDOWS
withNPY_OS_WIN_xxBIT
children, in the pattern ofNPY_OS_BSD
.It also removes
NPY_OS_MINGW
, which for the same reason never got defined. MINGW is not an OS, but a toolchain like MSVC. Maybe there could beNPY_BUILD_MINGW
andNPY_BUILD_MSVC
or some such?I'm not attached to this particular solution, or the names I've chosen. Input is welcome.
@Mousius: I won't pretend to understand the stack alignment problem in #23399. In loops_trigonometric.dispatch.c.src, can you confirm you wanted to force inlining on all windows systems, not just 32-bit?