Fix test for float32_cvt_i32

[gretay-js]

One of the C stubs in flambda-backend/tests/simd/ uses incompatible types. There is a macro that calls _mm_extract_ps which expects __m128 argument, but one of the uses of the macro is with the result of _mm_cvtps_epi32 which is of type __m128i. This issue was originally reported by @bclement-ocp.

This PR attempts to fix it:

• Add another macro that uses _mm_extract_epi32 instead of _mm_extract_ps for _mm_cvtps_epi32.
• Add standard to c_flags in this test directory, to get the warning about "incompatible type" in the CI.

[TheNumbat]

Fix looks fine, but need to figure out what's changed in the macOS CI

[xclerc]

(Given the timing, I wonder whether it could
simply be an upgrade to macOS Sequoia.)

[gretay-js]

Fix looks fine, but need to figure out what's changed in the macOS CI

The problem was with operations on NaNs. The problem was exposed by turning optimizations on: including :standard in flags implies -O2. For example, add of two NaNs is not commutative. An add operation on NaNs returns a NaN whose payload is one of the payloads of its inputs, according to IEEE 745, as far as I understand it. The tests we have are sensitve to NaN representation, and building the stubs.c with optimizations produces a slightly different result on MacOS. My proposed fix is to avoid NaNs in random tests (see 6916882). An alternative fix would be to consider equivalence up to NaNs as is already implemented in eqf'. @TheNumbat let me know which one you prefer.

(Given the timing, I wonder whether it could simply be an upgrade to macOS Sequoia.)

Looks like macos-15 on x86_64 is only available in a large image, which requires a subscription. I'll make a PR to upgrade to a small macos-15 on arm64 (some tests are failing) and we can discuss the trade-offs.

[TheNumbat]

I see, thanks. I would prefer to continue testing that the nan behavior is consistent with the C stubs, since our OCaml intrinsics don't depend on compiler flags - do you know what C operation(s) have a different result with -O2? We don't enable fast-math so the change is a little surprising.

[gretay-js]

There were a few differences. At least add and cmp unordered/ordered had different results. Some differences are due to producing a signalling NaN from in the random tests, and then operations turn it into quiet NaN or not, depending on optimization levels.

[TheNumbat]

I think we determined that the difference comes from clang flipping the src/dst register order or using a different instruction with -O2. I had assumed the C intrinsics guaranteed translation to a specific instruction/reg order, but apparently not, so we indeed can't rely on consistent NaN patterns from the C stubs. Let's change the tests to use eqf' so we still test NaNs but treat all NaNs as equivalent.