Spurious NaNs produced by trig functions with valid inputs on Windows GNU toolchains

[novacrazy]

I'm unsure what the root cause of this is, and have been unable to reproduce it in a minimal project for many months, but every so often trig functions such as sin/cos/sin_cos will produce NaN values on perfectly valid inputs, only when using the Windows GNU toolchains.

In a project I have these lines:

let (sin_phi, cos_phi) = phi.sin_cos();

assert!(!sin_phi.is_nan(), "SIN {} {}", sin_phi, phi);
assert!(!cos_phi.is_nan(), "COS {} {}", cos_phi, phi);

which panics with this message:

thread 'main' panicked at 'SIN NaN -0.044661168'

on nightly-x86_64-pc-windows-gnu (1.40.0-nightly (3a9abe3f0 2019-10-15))

The program is complex but deterministic, and produces no such issues on the Windows MSVC toolchains.

This occurs with no RUSTFLAGS, and with the Cargo.toml config of:

[profile.dev]
debug = true
opt-level = 3
incremental = false
debug-assertions = true
codegen-units = 32

[mati865]

Related to #53254

[mati865]

@novacrazy does your code use MMX instructions or packed_simd crate?

Discussion on Zulip about #53254 revealed this happens when using mingw libm and MMX instructions. I suspect this is the same case.

[novacrazy]

Yes, phi is a plain f32, but it is constructed from SIMD operations including .sum() (simd_reduce_add_unordered?) and .extract() (simd_extract) from the packed_simd crate.

[mati865]

Then it's the same as #53254 and I think there is no point in keeping it open.

This is (mostly?) packed_simd bug and should be fixed there, upstream tracking issue: rust-lang/packed_simd#72