-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExplicitConversion_FromSingle failing due to NaN != NaN #103347
Comments
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries |
Tagging subscribers to this area: @dotnet/area-system-numerics |
This issue is matching to tests jobs which log test names. Need to further constrain the match. |
Just hit this in #106040 for WasmTestOnChrome-ST-System.Runtime.Tests
Not sure why it didn't match in build analysis |
The test here should likely be filtered out on WASM for the time being, with a tracking issue against it. WASM isn't technically doing anything wrong here, normalizing WASM also has instructions that should guarantee the underlying bits are preserved, so it should be possible for it to be preserved and match the behavior of other targets (both for RyuJIT and Mono). |
Hm the weird thing here is that this seems to be an intermittent failure. I've checked and we definitely have passing runs of the test on the exact same config. |
Is there perhaps a difference in the WASM version or configuration options for the failing platform as compared to others? Maybe some machine specific issue that's only triggering in some scenarios? |
the tests are running in containers on the same helix queue so even the VM/machine should be the same... The only difference is the order of the tests, but I'm having a hard time imagining how that could be relevant |
|
According to Kusto test data this started happening on or before 2024-06-06. Given it's only happening intermittently and doesn't appear to be a blocker for 9.0 I'm moving it to 10.0 |
Couple of things could be responsible which might be explained by the test order:
But I'd like to push back against hte idea that bitwise comparison of two NaNs is a good idea. there are many NaN bitpatterns; all are semantically indistinguishable. Reasonable code should not depend on the bit pattern staying identical after computation |
This is a core thing frequently depended upon for SIMD, NaN boxing, etc. It also follows the IEEE 754 "recommended" guidelines, even if it's not strictly required by the IEEE 754 spec. The WASM 1.0 and 2.0 specs similarly:
However, the WASM specs do notably explicitly allow non-determinism for So while a given implementation is technically allowed to do "other things" (such as always canonicalizing NaN), its highly irregular to do so and that's why we have tests that validate such conversions are preserving bits and propagating payloads as expected. -- It's also notably cheaper to propagate and to preserve NaN as is then it is to canonicalize (particularly for things like |
@tannergooding @lambdageek what are the next steps here ? |
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=768837&view=results
Build error leg or test failing: System.Tests.HalfTests.ExplicitConversion_FromSingle
Pull request:
Error Message
Fill the error message using step by step known issues guidance.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=768837
Error message validated:
[FAIL.*System.Tests.HalfTests.ExplicitConversion_FromSingle
]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 8/8/2024 7:39:18 PM UTC
Report
Summary
The text was updated successfully, but these errors were encountered: