test_mul_add failt in debug mode for arm-unknown-linux-gnueabi

c469d49
Opened by Marco A L Barbosa at 2024-03-11 15:17:05

This following test extract from libstd:

#[cfg(test)]
mod tests {
    macro_rules! assert_approx_eq {
        ($a:expr, $b:expr) => ({
            let (a, b) = (&$a, &$b);
            assert!((*a - *b).abs() < 1.0e-6,
                    "{} is not approximately equal to {}", *a, *b);
        })
    }

    #[test]
    fn f64_test_mul_add() {
        assert_approx_eq!((-12.3f64).mul_add(-4.5, -6.7), 48.65);
        assert_approx_eq!(0.0f64.mul_add(8.9, 1.2), 1.2);
    }

    #[test]
    fn f32_test_mul_add() {
        assert_approx_eq!((-12.3f32).mul_add(-4.5, -6.7), 48.65);
        assert_approx_eq!(0.0f32.mul_add(8.9, 1.2), 1.2);
    }
}

fails to run in raspbarry pi 3 and in qemu when compiled in debug mode for the target arm-unknown-linux-gnueabi. It works if compiled in release mode. rustc 1.24.0-nightly (250b49205 2017-12-21) was used.

To test using cross, create a project execute cross test --target arm-unknown-linux-gnueabi. cross execute the test using qemu-arm, but I think it is not a problem with qemu because the test also fails running in a raspbarry pi 3. Also the test works if compiled in release mode.

qemu error:

---- tests::f32_test_mul_add stdout ----
        thread 'tests::f32_test_mul_add' panicked at '38.4 is not approximately equal to 1.2', src/lib.rs:20:8

---- tests::f64_test_mul_add stdout ----
        thread 'tests::f64_test_mul_add' panicked at '38.4 is not approximately equal to 1.2', src/lib.rs:14:8

raspberry pi error:

---- tests::f32_test_mul_add stdout ----
        thread 'tests::f32_test_mul_add' panicked at '-12.3 is not approximately equal to 48.65', src/lib.rs:19:8

---- tests::f64_test_mul_add stdout ----
        thread 'tests::f64_test_mul_add' panicked at '0 is not approximately equal to 48.65', src/lib.rs:13:8
  1. Triage: Can this still be reproduced? Wanted to check since 6 years have passed and circumstances might have changed.

    Martin Nordholts at 2023-09-27 17:35:12

  2. @Enselic Yes, the problem is still exists. And sometimes it is reproduced in the release builds

    Valery Klachkov at 2024-03-11 15:17:05