Closed alexcrichton closed 1 year ago
Thanks for the fix! Can you please add a comment to the test regarding INT_MAX not being representable and thus not testable? That is a very useful bit of information to know when looking at the test.
Sure thing!
This fixes some minor issues I encountered when running these tests. The first is a test for the
i32x4.relaxed_trunc_f32x4_s
instruction which asserted that2147483647.0
(INT_MAX) would get translated to INT_MAX through the conversion. This float value, however, is not representable inf32
. The two other closest integers thatf32
can represent are 2147483648 and 2147483520, so it's not actually possible to exercise a conversion from precisely INT_MAX to INT_MAX. Due to float parsing this meant that the value was getting rounded up to 2147483648 which exceeded INT_MAX which when usingcvttpd2dq
on x86 would cause INT_MIN to get returning, failing the test. I updated the test to pass something in-bounds (2 in this case) since the other edge cases are already tested.The other issue fixed in this commit is that many tests asserted that INT_MIN was a possible result but the representation of INT_MIN was missing a 0 in its hexadecimal representation, so zeros were appended.