Skip to content

Subnormal f64 to f32 cast is incorrect in CTFE #113407

Closed
rust-lang/rustc_apfloat
#1

Description

@cbeuw
pub fn main() {
    let f = f64::from_bits(0x19873cc2) as f32;
    println!("{:x}", f.to_bits());
    println!("{}", f == 0.);
}
$ rustc -Zmir-opt-level=2 -Copt-level=3 repro.rs && ./repro
1
false
$ ../miri/miri run repro.rs 2> /dev/null
1
false
$ rustc -Zmir-opt-level=1 -Copt-level=3 repro.rs && ./repro
0
true

It should print 0 and true, according to the equivalent C program: https://godbolt.org/z/7Gq51a1Yh

This is probably another apfloat bug

$ rustc --version -v 
rustc 1.72.0-nightly (d9c13cd45 2023-07-05)
binary: rustc
commit-hash: d9c13cd4531649c2028a8384cb4d4e54f985380e
commit-date: 2023-07-05
host: aarch64-unknown-linux-gnu
release: 1.72.0-nightly
LLVM version: 16.0.5

(reproducible on x86 as well)

cc @eddyb @wesleywiser @RalfJung

Activity

  1. RalfJung commented on Jul 6, 2023

    @RalfJung
    Member

    This is strange: https://godbolt.org/z/14GxTsfoM

    LLVM and Rust are both using apfloat for compile-time float computations, and yet the MIR opts produce 1 and LLVM produces 0. Is this something that was fixed in upstream apfloat but we don't have the fix yet?

  2. cbeuw commented on Jul 6, 2023

    @cbeuw
    ContributorAuthor

    Rust's apfloat port is old and unupdated for a long while. For instance #102403 was fixed upstream 6 years ago llvm/llvm-project@f2c2851

  3. nikic commented on Jul 6, 2023

    @nikic
    Contributor

    The relevant fix is probably https://reviews.llvm.org/D127140?

  4. RalfJung commented on Jul 6, 2023

    @RalfJung
    Member

    #113416 should work around this.

  5. added
    I-slowIssue: Problems and improvements with respect to performance of generated code.
    A-mir-optArea: MIR optimizations
    A-floating-pointArea: Floating point numbers and arithmetic
    A-const-propArea: Constant propagation
    on Jul 10, 2023
  6. eddyb commented on Jul 13, 2023

    @eddyb
    Contributor

    While trying to trigger a different issue involving float<->float conversions, I believe my rustc_apfloat fuzzer (after commit rust-lang/rustc_apfloat@439177a) reproduced this one instead:

    image

    (which is good confirmation that we can find such things. too bad about the FMA NaNs polluting fuzzer outputs)

    EDIT: also see the longer update post at #55993 (comment)

  7. eddyb commented on Jul 18, 2023

    @eddyb
    Contributor

    As per #55993 (comment), this is now fixed in rust-lang/rustc_apfloat.

  8. cbeuw commented on Jul 18, 2023

    @cbeuw
    ContributorAuthor

    This should be reopened until rustc starts using the stand-alone crate

  9. eddyb commented on Jul 18, 2023

    @eddyb
    Contributor

    Uh oh I did not do that, GH must've gotten overzealous cross-repo.

  10. reopened this on Jul 18, 2023
  11. RalfJung commented on Jul 18, 2023

    @RalfJung
    Member

    You said "fixes #113407" in that PR, GH did the rest. ;)

  12. added a commit that references this issue on Jul 26, 2023
    0d95f91
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-const-propArea: Constant propagationA-floating-pointArea: Floating point numbers and arithmeticA-mir-optArea: MIR optimizationsI-slowIssue: Problems and improvements with respect to performance of generated code.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions