close/reopen

Put a triage label on this, as the deadline is coming up and there are problems.

@h-vetinari Ping, because ISTR that you were involved last time we updated the windows version.

The failures seem to mostly come fromtest_unary_spurious_fpexception and accuracy in some ufuncs.

The failures seem to mostly come from test_unary_spurious_fpexception and accuracy in some ufuncs.

• Thetest_unary_spurious_fpexception seems to come from OpenBLAS
• The accuracy failures are in the no blas builds.

@h-vetinari Ping, because ISTR that you were involved last time we updated the windows version.

Thanks for the ping. The only place where this really becomes relevant is for linking tonpymath.lib. Anyone doing that will most likely need to update to VS2022.

Given that VS2019 is EOL for over a year, and that VS2022 is an ABI-compatible update, this should not be an undue burden. The timing matches well, I've just picked up theproposal to move to VS2022 in conda-forge again.

The only place where this really becomes relevant is for linking tonpymath.lib

Isn't this snippet meant to make anpymath.lib that can be used by older linkers?

The test_unary_spurious_fpexception seems to come from OpenBLAS

Maybe related to#29039 which updates OpenBLAS

Isn't this snippet meant to make anpymath.lib that can be used by older linkers?

Not AFAIU. That's about reusing/sharing the objects in the static library between MSVC and mingw, and thecomment from the upstream devs at the time was

Mixing static libraries or object files between mingw and msvc is not
supported, and not expected to work, in general. You might have been lucky
and your library might have been simple enough not to hit any problematic
case though.

The virality of the msvc toolset concerns being able to link to something built with VS2022 (which - at least on paper - then also requires VS2022)

Rather than latest, it would be better to explicitly use vs2022.

@seiko2plus Thetest_unary_spurious_fpexception are inufunc = <ufunc 'spacing'> forf andd. I see that test is already skipped fore. Should we just skip it forf andd as well? Is there something we should do for SIMD instead?

The only place where this really becomes relevant is for linking tonpymath.lib. Anyone doing that will most likely need to update to VS2022.

Agreed, which means we need to update to the 2022 image in SciPy first before merging this.

We should probably do that asap and then merge this and backport it to the 2.3.x branch. before releasing 2.3.0. Otherwise it'll become a potentially risky change in 2.3.1 or 2.3.2.

Look like i need to skip spacing test for window

vs2022 changes:https://devblogs.microsoft.com/cppblog/the-fpcontract-flag-and-changes-to-fp-modes-in-vs2022/

vs2022 changes:https://devblogs.microsoft.com/cppblog/the-fpcontract-flag-and-changes-to-fp-modes-in-vs2022/

Windows Server 2019: Uses older MSVC that generates FMA contractions by default
Windows Server 2022: Uses VS2022's MSVC which does NOT generate FMA contractions by default

This change significantly affects floating-point precision, especially for transcendental functions

So we need to add the /fp:contract flag to MSVC builds.

Windows Server 2022: Uses VS2022's MSVC which does NOT generate FMA contractions by default

Note that meson shows FMA3 enabled, but evidently a flag is required for msvc in vs2022. I'm not clear on whether meson should handle that or not. Unfortunately, the/fp:contract flag is new. Maybe disable FMA3 if the flag is missing for recent msvc?@rgommers Thoughts?

Note that meson shows FMA3 enabled, but evidently a flag is required for msvc in vs2022. I'm not clear on whether meson should handle that or not. Unfortunately, the/fp:contract flag is new. Maybe disable FMA3 if the flag is missing for recent msvc?@rgommers Thoughts?

@seiko2plus knows more exactly where it goes, but I'm pretty it's in themeson_cpu/ machinery in this repo, not upstream. Or maybe in the top-levelmeson.build file right undersubdir('meson_cpu'). If we see FMA enabledand we see thatcc.get_id() == 'msvc', then add the/fp:contract flag to project-global C/C++ flags.

Can we run wheel builder CI on this patch?
I need to check wheel CI reactions on this patch.

Can we run wheel builder CI on this patch?

Append[build wheel][wheel build] to the header line of the last commit.

Note that /fp:contract is not supported MSVC < 19.14

Note that /fp:contract is not supported MSVC < 19.14

Should be fine, since our minimum supported version is 19.20:

You need to do the update this way:

  FMA3.update(args: {'val': '/arch:AVX2', 'match': clear_arch})  FMA3.update(args: {'val': '/fp:contract'})

You need to do the update this way:

  FMA3.update(args: {'val': '/arch:AVX2', 'match': clear_arch})  FMA3.update(args: {'val': '/fp:contract'})

isn't it overriding the args for FMA3 ?Correct me if i am wrong

Hi@charris@r-devulap

1. Now floating-point contract flag for 32-bit MSVC builds only is added to meson build .
2. Skip spacing tests with NaN on Windows MSVC (all dtypes) only.

Please have a review to this patch.
Thanks

#29116 is working now. There is a bogus circleci failure that can be ignored. I'm curious if@r-devulap suggestion of putting the args in a list works.

The PyPy failure can be ignored.

@rgommers@charris@r-devulap
This patch seems ok, please have a review and merge.