All the windows 32 bit wheel builds are failing in the computation of sin/cos, I suspect an SIMD problem. The windows no BLAS build fails the same way, makes me wonder if it also 32 bits.

Note that I disabled the spacing warnings test for all floats, which is why the 64 bit windows builds are passing.

@rdevulap Thoughts?

It might also be the case that all 'no BLAS' builds fail, both on 32 and 64 bit windows. Which seems strange, there seems no good reason that using BLAS should make a difference in the computation of sin/cos. Maybe something in the meson build?

@rgommers Thoughts on this?

Also, ping @stefanv for the meson build.

Cross-linking gh-28955 since that PR contains these same changes and also showed SIMD issues.

It doesn't look like it has anything to do with BLAS yes/no. All 32-bit builds are failing on:

  FAILED _core/tests/test_umath.py::TestAVXFloat32Transcendental::test_sincos_float32 - AssertionError: Arrays are not almost equal up to 2 ULP (max difference is 1.80991e+09 ULP)
  FAILED _core/tests/test_umath_accuracy.py::TestAccuracy::test_validate_fp16_transcendentals[cos] - AssertionError: Arrays are not almost equal up to 1 ULP (max difference is 2302 ULP)
  FAILED _core/tests/test_umath_accuracy.py::TestAccuracy::test_validate_fp16_transcendentals[sin] - AssertionError: Arrays are not almost equal up to 1 ULP (max difference is 1491 ULP)

That 32-bit builds don't use a scipy-openblas32 wheel isn't really relevant to these failures. Seems to me like a change in compiler version is likely causing these issues.

Ah, you meant the MSVC, x86 Python , no BLAS job - yes, it says x86 not x64 or x86-64 so that's a 32-bit job.

I suspect the primary failure is in test_umath.TestAVXFloat32Transcendental:test_sincos_float32.

Do we need to update the blocklist?

Do we need to update the blocklist

The errors are huge, much worse than the MS library is likely to return. I think the problem is with our SIMD implementation/dispatch. The fact that it is x86 specific is odd, I didn't think AVX was available on that platform. Disabling something on the 32 bit platform might work. I don't even know what the test is using for the computation. Meson enables the same SIMD support on both platforms.

On vs2022:

Enabled : SSE3 SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL

On vs2019:

Enabled : SSE3 SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL

Possibly a compiler bug

Do we need to update the blocklist

The errors are huge, much worse than the MS library is likely to return. I think the problem is with our SIMD implementation/dispatch. The fact that it is 32 specific is odd. Disabling something on 32 bits might work. I don't even know what the test is using for the computation. Meson enables the same SIMD support on both platforms.

On vs2022:

Enabled : SSE3 SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL

On vs2019:

Enabled : SSE3 SSSE3 SSE41 POPCNT SSE42 AVX F16C FMA3 AVX2 AVX512F AVX512CD AVX512_SKX AVX512_CLX AVX512_CNL AVX512_ICL

Possibly a compiler bug

Maybe we need to disptach baseline SSE runtime on 32 bit and avoid SIMD path on those.

I note that meson enables a lot of SIMD that aren't likely available to 32 bit code, AVX in particular. Perhaps we are using some macro that has changed in vs2022.

Issue is solved now on my PR for MSVC no BLAS

@charris were these tests passing when it was run on windows-2019 and failing only on windows-2022?

The ULP errors are extremely large AssertionError: Arrays are not almost equal up to 2 ULP (max difference is 1.80991e+09 ULP). I have seen this happen when FMA isn't used. That means we are using SIMD paths with Highway but not generating an FMA instruction. Still figuring out why.

Looks like @abhishek-iitmadras already pointed to the problem: #28955 (comment) :)