`f64::log` precision change in 1.82 nightly

[ogoffart]

Our CI started to report an error today with nightly on Linux (other platforms are fine).
Simplified the test case is because of a small difference in the computation of log.

(I know it's bad practice to do equality tests on float, but I thought I'd report this behavior change anyway as i don't know if this was intentional).

Code

I tried this code:

fn main() {
    println!("Hello, world! {}", 9f64.log(3.) );
    assert_eq!(9f64.log(3.) , 2.)
}

I expected to see this happen:

Hello, world! 2 and no panics. As this happens in stable

Instead, this happened:

Hello, world! 2.0000000000000004
thread 'main' panicked at src/main.rs:3:5:
assertion `left == right` failed
  left: 2.0000000000000004
 right: 2.0

Version with regression

rustc 1.82.0-nightly (612a33f 2024-07-29)
(Linux only)

[apiraino]

Bisection seems to indicate this comes after updating out compiler-builtins crate: 80d8270

I guess this is "expected"? cc: @nicholasbishop

[tgross35]

This is probably a result of the linkage change in rust-lang/compiler-builtins#594 since the actual implementation hasn't changed in 5 years https://github.com/rust-lang/libm/blob/279e5f6abe0a2ca9066962d9ec894f0df1f417ac/src/math/log.rs..

Could you dwarfdump the final binaries and take a look whether system or compiler_builtins symbols are being linked?

[tgross35]

Obviously we want to have the correct values and will try to make things work, thanks bringing it up. Just note that the docs are extremely lenient here:

The precision of this function is non-deterministic. This means it varies by platform, Rust version, and can even differ within the same execution from one invocation to the next.

I think that if you are relying on exact results for CI then that may prove to be pretty platform-dependent.

[adrian17]

FWIW, we just hit it in our CI too; looks like the runtime value no longer equals the compiler constant-folded result on our platforms.
Not sure how we'll handle it yet.

(EDIT: forgot to add: we noticed this with exp instead of log, but I'm assuming it's caused by the same change)

[saethlin]

looks like the runtime value no longer equals the compiler constant-folded result on our platforms.

I believe that is #124364

I'm deliberately not labeling this issue as I-unsound because I think this issue is just noticing a specific instance of the above-linked issue.

[alexpyattaev]

Arguably, this is a true regression, and not a simple "log is fuzzy anyway". Reason being that the resulting error is 2 * f64::EPSILON, and not one ulp as advertised in the implementation of the log function.

FYI dwarfdump is attached. As far as I could read it, it is using the compiler's version of log function.
dwarfdump.txt.gz

Also interesting that in release build there is no issue.

[tgross35]

Thanks for posting that, relevant bit of the above:

0x000e7fbb:         DW_TAG_subprogram
                      DW_AT_low_pc      (0x0000000000058ff0)
                      DW_AT_high_pc     (0x0000000000058ffd)
                      DW_AT_frame_base  (DW_OP_reg6 RBP)
                      DW_AT_name        ("log")
                      DW_AT_decl_file   ("/rust/deps/compiler_builtins-0.1.114/src/macros.rs")
                      DW_AT_decl_line   (468)
                      DW_AT_external    (true)

Just to make sure, could you do the same with an older nightly and check that the system version was getting linked before?

[alexpyattaev]

I do not have a previous nightly left, but 1.81.0-beta.2 that does not exhibit the bug produces the following

dwarfdump.txt.gz

The specific section for log function that you refer to is not there.