Skip to content
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

Some num tests fail for {i586, i686, x86_64}-unknown-linux-gnu #46948

Closed
malbarbo opened this issue Dec 22, 2017 · 5 comments
Closed

Some num tests fail for {i586, i686, x86_64}-unknown-linux-gnu #46948

malbarbo opened this issue Dec 22, 2017 · 5 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. O-x86_32 Target: x86 processors, 32 bit (like i686-*) T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@malbarbo
Copy link
Contributor

Consider the following tests extract from libstd:

#[cfg(test)]
mod tests {
    use std::f32;
    use std::f64;

    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 test_mul_add() {
        let nan = f64::NAN;
        let inf = f64::INFINITY;
        let neg_inf = f64::NEG_INFINITY;
        assert_approx_eq!(12.3f64.mul_add(4.5, 6.7), 62.05);
        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);
        assert_approx_eq!(3.4f64.mul_add(-0.0, 5.6), 5.6);
        assert!(nan.mul_add(7.8, 9.0).is_nan());
        assert_eq!(inf.mul_add(7.8, 9.0), inf);
        assert_eq!(neg_inf.mul_add(7.8, 9.0), neg_inf);
        assert_eq!(8.9f64.mul_add(inf, 3.2), inf);
        assert_eq!((-3.2f64).mul_add(2.4, neg_inf), neg_inf);
    }

    #[test]
    fn f32_test_float_bits_conv() {
        assert_eq!((1f32).to_bits(), 0x3f800000);
        assert_eq!((12.5f32).to_bits(), 0x41480000);
        assert_eq!((1337f32).to_bits(), 0x44a72000);
        assert_eq!((-14.25f32).to_bits(), 0xc1640000);
        assert_approx_eq!(f32::from_bits(0x3f800000), 1.0);
        assert_approx_eq!(f32::from_bits(0x41480000), 12.5);
        assert_approx_eq!(f32::from_bits(0x44a72000), 1337.0);
        assert_approx_eq!(f32::from_bits(0xc1640000), -14.25);

        // Check that NaNs roundtrip their bits regardless of signalingness
        // 0xA is 0b1010; 0x5 is 0b0101 -- so these two together clobbers all the mantissa bits
        let masked_nan1 = f32::NAN.to_bits() ^ 0x002A_AAAA;
        let masked_nan2 = f32::NAN.to_bits() ^ 0x0055_5555;
        assert!(f32::from_bits(masked_nan1).is_nan());
        assert!(f32::from_bits(masked_nan2).is_nan());

        assert_eq!(f32::from_bits(masked_nan1).to_bits(), masked_nan1);
        assert_eq!(f32::from_bits(masked_nan2).to_bits(), masked_nan2);
    }

    #[test]
    fn f64_test_float_bits_conv() {
        assert_eq!((1f64).to_bits(), 0x3ff0000000000000);
        assert_eq!((12.5f64).to_bits(), 0x4029000000000000);
        assert_eq!((1337f64).to_bits(), 0x4094e40000000000);
        assert_eq!((-14.25f64).to_bits(), 0xc02c800000000000);
        assert_approx_eq!(f64::from_bits(0x3ff0000000000000), 1.0);
        assert_approx_eq!(f64::from_bits(0x4029000000000000), 12.5);
        assert_approx_eq!(f64::from_bits(0x4094e40000000000), 1337.0);
        assert_approx_eq!(f64::from_bits(0xc02c800000000000), -14.25);

        // Check that NaNs roundtrip their bits regardless of signalingness
        // 0xA is 0b1010; 0x5 is 0b0101 -- so these two together clobbers all the mantissa bits
        let masked_nan1 = f64::NAN.to_bits() ^ 0x000A_AAAA_AAAA_AAAA;
        let masked_nan2 = f64::NAN.to_bits() ^ 0x0005_5555_5555_5555;
        assert!(f64::from_bits(masked_nan1).is_nan());
        assert!(f64::from_bits(masked_nan2).is_nan());

        assert_eq!(f64::from_bits(masked_nan1).to_bits(), masked_nan1);
        assert_eq!(f64::from_bits(masked_nan2).to_bits(), masked_nan2);
    }
}

Using rustc 1.24.0-nightly (250b49205 2017-12-21) it fails in debug mode for the targets {i586, i686}-unknown-linux-gnu but works in release mode. It works in both release and debug mode for x86_64-unknown-linux-gnu.

Using rustc 1.23.0-beta.2 (c9107ee93 2017-12-08) or rustc 1.22.1 (05e2e1c41 2017-11-22) only tests::test_mul_add works in release mode for {i586, i686, x86_64}-unknown-linux-gnu. For debug mode all tests fails for {i586, i686}-unknown-linux-gnu, tests::test_mul_add works for x86_64-unknown-linux-gnu.

@pietroalbini pietroalbini added A-testsuite Area: The testsuite used to check the correctness of rustc O-x86 T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jan 30, 2018
@estebank
Copy link
Contributor

CC #53081

@mati865
Copy link
Contributor

mati865 commented Dec 16, 2019

I don't see how this is related to #53081.

Retested with latest nightly:
Debug mode i686:

running 3 tests
test tests::test_mul_add ... ok
test tests::f64_test_float_bits_conv ... FAILED
test tests::f32_test_float_bits_conv ... FAILED

failures:

---- tests::f64_test_float_bits_conv stdout ----
thread 'tests::f64_test_float_bits_conv' panicked at 'assertion failed: `(left == right)`
  left: `9221870836978985642`,
 right: `9219619037165300394`', src\lib.rs:70:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

---- tests::f32_test_float_bits_conv stdout ----
thread 'tests::f32_test_float_bits_conv' panicked at 'assertion failed: `(left == right)`
  left: `2144687445`,
 right: `2140493141`', src\lib.rs:49:9


failures:
    tests::f32_test_float_bits_conv
    tests::f64_test_float_bits_conv

test result: FAILED. 1 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out

Release mode works fine for i686, x86_64 works fine regardless the mode.

Separated the only two cases which are failing:

use std::f32;
use std::f64;

fn f32_bug() {
    let masked_nan2 = f32::NAN.to_bits() ^ 0x0055_5555;
    assert_eq!(f32::from_bits(masked_nan2).to_bits(), masked_nan2);
}

fn f64_bug() {
    let masked_nan1 = f64::NAN.to_bits() ^ 0x000A_AAAA_AAAA_AAAA;
    assert_eq!(f64::from_bits(masked_nan1).to_bits(), masked_nan1);
}

@estebank
Copy link
Contributor

Misread the context while triaging. Sorry for the noise.

Centril added a commit to Centril/rust that referenced this issue Dec 20, 2019
Teach `compiletest` to ignore platform triples

The UI tests are written assuming `--remap-path-prefix` is *not used* (`remap-debuginfo` in `config.toml`). The consequence is that the error messages may include paths and snippets into the standard library. When `remap-debuginfo` is enabled, these messages change in format and structure because `rustc` will not show paths and snippets into the standard library.

This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without `remap-debuginfo`, but the `dist` artifacts are built separately with `remap-debuginfo` enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with `remap-debuginfo` enabled. This also affects developers and distributors who use `remap-debuginfo`.

To sidestep this problem, we add a way to ignore tests in specific platform triples, and update the overly broad `ignore-x86` rule in affected tests.

Address rust-lang#46948, rust-lang#54546, rust-lang#53081.
bors added a commit that referenced this issue Dec 28, 2019
Teach `compiletest` to ignore platform triples

The UI tests are written assuming `--remap-path-prefix` is *not used* (`remap-debuginfo` in `config.toml`). The consequence is that the error messages may include paths and snippets into the standard library. When `remap-debuginfo` is enabled, these messages change in format and structure because `rustc` will not show paths and snippets into the standard library.

This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without `remap-debuginfo`, but the `dist` artifacts are built separately with `remap-debuginfo` enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with `remap-debuginfo` enabled. This also affects developers and distributors who use `remap-debuginfo`.

To sidestep this problem, we add a way to ignore tests in specific platform triples, and update the overly broad `ignore-x86` rule in affected tests.

Address #46948, #54546, #53081.
@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Jun 14, 2020

#73288 is an exact duplicate of this issue. I'm closing this one in favor of #73288 since it has a bit more discussion on it.

There's also #73328 to document what guarantees we make around NaN payloads/signedness.

@RalfJung
Copy link
Member

RalfJung commented Sep 17, 2023

The issue title says:

Some num tests fail for {i586, i686, x86_64}-unknown-linux-gnu

However the text seems to say that this always works on x86_64 (and checking it on the playground, it does work right now). I'm also not aware of floating-point trouble on x86_64. So indeed I assume this is a duplicate of #73288, now tracked as #115567.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc C-bug Category: This is a bug. O-x86_32 Target: x86 processors, 32 bit (like i686-*) T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants