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.