Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Closed
wants to merge 1 commit into from

Conversation

cbrt64
Copy link
Contributor

@cbrt64 cbrt64 commented May 25, 2023

When #20884 added NPY_OS_WIN64, the meaning of NPY_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 adding NPY_OS_WINDOWS with NPY_OS_WIN_xxBIT children, in the pattern of NPY_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 be NPY_BUILD_MINGW and NPY_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?

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.
@Mousius
Copy link
Member

Mousius commented May 25, 2023

@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 get/set for lanes iirc). The FINLINE was for the 32-bit windows calling pattern which places everything on stack, the theory was it was overflowing due to some alignment issues; on 64-bit windows I believe this function should be safe as the 64-bit calling convention will use the floating point registers instead.

TLDR; It should only need to inline on 32-bit windows

@seberg
Copy link
Member

seberg commented May 25, 2023

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.

@cbrt64
Copy link
Contributor Author

cbrt64 commented May 25, 2023

I can do that. I'm thinking just use _WIN64 like downstream is the simplest for now. Also it's already tested. Do you want a new PR, and keep this one for later, or just force push here?

@seberg seberg added this to the 1.25.0 release milestone May 29, 2023
@charris charris added the 09 - Backport-Candidate PRs tagged should be backported label Jun 5, 2023
seberg added a commit to seberg/numpy that referenced this pull request Jun 14, 2023
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]>
@seberg seberg removed the 09 - Backport-Candidate PRs tagged should be backported label Jun 14, 2023
@seberg seberg modified the milestones: 1.25.0 release, 2.0.0 release Jun 14, 2023
charris pushed a commit to charris/numpy that referenced this pull request Jun 14, 2023
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]>
@seberg seberg modified the milestones: 2.0.0 release, 2.1.0 release Jan 31, 2024
@charris
Copy link
Member

charris commented Aug 1, 2024

Going to push this off to 2.2, but it looks like is needs a refresh in any case. Maybe close?

@charris charris modified the milestones: 2.1.0 release, 2.2.0 release Aug 1, 2024
@mattip mattip self-assigned this Aug 21, 2024
@charris
Copy link
Member

charris commented Nov 22, 2024

Pushing off to 2.3. Is this still relevant?

@charris charris modified the milestones: 2.2.0 release, 2.3.0 release Nov 22, 2024
@cbrt64 cbrt64 closed this Jan 14, 2025
@cbrt64 cbrt64 deleted the fix-npy_os_h branch January 14, 2025 06:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

5 participants