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

Inconsistent truncation of -0.0 #617

Open
tgross35 opened this issue May 20, 2024 · 6 comments
Open

Inconsistent truncation of -0.0 #617

tgross35 opened this issue May 20, 2024 · 6 comments
Labels
llvm This issue needs to be fixed in LLVM

Comments

@tgross35
Copy link
Contributor

#![feature(f128, f16)]

use core::hint::black_box;

extern "C" {
    fn __truncdfhf2(a: f64) -> f16;
}

fn main() {
    let a = -0_f64;
    let res_sys: f16 = unsafe { __truncdfhf2(a) };
    let res_llvm: f16 = black_box(a) as f16;
    let res_builtins: f16 = compiler_builtins::float::trunc::__truncdfhf2(a);
    dbg!(res_sys, res_llvm, res_builtins);
}
[src/lib.rs:108:1] res_sys = 0x0000
[src/lib.rs:108:1] res_llvm = 0x0000
[src/lib.rs:108:1] res_builtins = 0x8000
@tgross35
Copy link
Contributor Author

Ok this is actually the builtin symbol doing the wrong thing. f64 -> f32 keeps the sign for -0, as does rustc_apfloat, so I think compiler-builtins is correct here.

@tgross35 tgross35 changed the title Inconsistent runcation of -0 Inconsistent truncation of -0 May 20, 2024
@tgross35 tgross35 changed the title Inconsistent truncation of -0 Inconsistent truncation of -0.0 May 20, 2024
@tgross35
Copy link
Contributor Author

Even more float conversions seem wrong on some platforms when called directly. E.g. arm-unknown-linux-gnueabihf has the following:

add_f32(0.0, -inf): crate: -inf, sys: NaN
extend_f32_f64(-0.0,): crate: -0.0, sys: -1.0609978955e-314
mul_f32(1e-45, 1e-45): crate: 0.0, sys: NaN
trunc_f64_f32(-0.0,): crate: -0.0, sys: 0.0

I am getting these from the benchmark tests that call external symbols rather than assembly #617

@tgross35
Copy link
Contributor Author

tgross35 commented May 20, 2024

On x86_64-pc-windows-msvc, x86_64-pc-windows-gnu,

conv_f32_u128(0.0,): crate: 0, sys: 225082651231465353564815136481731410602
conv_f32_i128(0.0,): crate: 0, sys: -115199715689473109898559470950036800854

Interestingly, that test seems to pass on the i686 Windows targets

@Amanieu
Copy link
Member

Amanieu commented May 21, 2024

Perhaps this is due to an issue in libgcc's implementation of these functions?

@tgross35
Copy link
Contributor Author

I suppose so. I need to dig a bit more into what is actually getting linked, I'll open issues in the relevant projects once I can reproduce them in C.

@tgross35
Copy link
Contributor Author

tgross35 commented May 22, 2024

Few more inconsistencies where it seems like the system symbol is wrong. I guess we are testing against the correct assembly versions, but the named symbols available are wrong.

On i586-unknown-linux-gnu:

add_f128(0x00000000000000000000000000000000, 0x00000000000000000000000000000000): crate: 0x00000000000000000000000000000000, sys: 0x00000001000000040008000000000000
sub_f128(0x00000000000000000000000000000000, 0x00000000000000000000000000000000): crate: 0x00000000000000000000000000000000, sys: 0x80000001000000040008000000000000
powi_f32(1.0000001, -32768): crate: 0.99610233, sys: 0.9961014

On powerpc64le-unknown-linux-gnu:

extend_f32_f128(0.0,): crate: 0x00000000000000000000000000000000, sys: 0x80000000000000000000000000000000

Possibly related to the other ABI problems like llvm/llvm-project#92246.

Also on powerpc64le-unknown-linux-gnu, __fixunssfsi has a shift right overflow panic. I am pretty suspicious of this one, maybe it's just an old qemu version since I get a different error testing locally.

thread 'main' panicked at /rustc/791adf759cc065316f054961875052d5bc03e16c/library/core/src/ops/bit.rs:614:1:
attempt to shift right with overflow
stack backtrace:
qemu: Unsupported syscall: 383
qemu: Unsupported syscall: 383
...
  14:       0x4000523670 - rust_begin_unwind
                               at /rustc/791adf759cc065316f054961875052d5bc03e16c/library/std/src/panicking.rs:652:5
  15:       0x400002cd94 - core::panicking::panic_fmt::hb7734d8d5340d0ff
                               at /rustc/791adf759cc065316f054961875052d5bc03e16c/library/core/src/panicking.rs:72:14
  16:       0x400002d970 - core::panicking::panic_const::panic_const_shr_overflow::h18e0443d138c13b2
                               at /rustc/791adf759cc065316f054961875052d5bc03e16c/library/core/src/panicking.rs:179:21
  17:       0x40004f8adc - <u32 as core::ops::bit::Shr>::shr::h3d32457f86482582
                               at /rustc/791adf759cc065316f054961875052d5bc03e16c/library/core/src/ops/bit.rs:588:17
  18:       0x40004f57e8 - compiler_builtins::float::conv::float_to_int_inner::h20f2990f410a885c
                               at /checkout/src/float/conv.rs:223:24
  19:       0x40004f4318 - compiler_builtins::float::conv::float_to_unsigned_int::h2c46ea36e0a8c0b6
                               at /checkout/src/float/conv.rs:161:5
  20:       0x40004f258c - compiler_builtins::float::conv::__fixunssfsi::h499e282469decc4b
                               at /checkout/src/float/conv.rs:237:9
  21:       0x40000da6f0 - float_conv::conv_f32_u32::crate_fn::h3d40db525d4f4959
                               at /checkout/testcrate/src/bench.rs:123:17
  22:       0x40000da268 - float_conv::conv_f32_u32::h8400d8bbfdc9131d
                               at /checkout/testcrate/src/bench.rs:158:33
  23:       0x40000df4d8 - float_conv::float_conv::h7a3178d7d3386116
                               at /cargo/registry/src/index.crates.io-6f17d22bba15001f/criterion-0.5.1/src/macros.rs:71:17

@tgross35 tgross35 added the llvm This issue needs to be fixed in LLVM label Aug 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
llvm This issue needs to be fixed in LLVM
Projects
None yet
Development

No branches or pull requests

2 participants