[WIP] Implement cbrt and hypot function calls

[kungfukennyg]

Implements missing cbrt/hypot function calls as per #667.

Note that this PR is in progress -- I still need to determine what other function calls are missing.

[RalfJung]

Closing and re-opening to hopefully deconfuse Travis.

[RalfJung]

Hm dang. Seems like Travis just does not test "Draft" PRs, but AppVeyor does? This is silly.

[kungfukennyg]

I marked it as ready for review, let's see if that helps.

[RalfJung]

It does, and shows a legit failure:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `1.6261333316791688`,
 right: `1.6261333316791686`', $DIR/cmath.rs:10:5

That's why I don't like floating point stuff. ;)

[oli-obk]

I guess you can round both values or use one of the "almost eq" crates for float assertions

[RalfJung]

Well, not really the crates, but inlining that shouldn't be too hard, even without fabs.

fn almost_eq(x: f64, y: f64) -> bool {
    const EPSILON: f64 = 1e-20;
    let diff = x-y;
    diff < EPSILON && diff > -EPSILON
}

[RalfJung]

Also, this "non-determinism" (not really but almost) makes me wonder if we should require a flag? This will mean that e.g. a "cross-Miri" running Linux code on macOS will not behave the same than when "native Miri" runs Linux code on Linux.

But I also don't want 200 flags. So I am inclined to just accept this kind of divergence here. Once we have a "communication with the host OS" flag, we could use that.

[oli-obk]

Well... the clean solution would be to add these functions to librustc_apfloat so we have actual soft impls that are the same everywhere

[RalfJung]

Sure, that would be best.

[kungfukennyg]

Would I add the functions to librustc_apfloat/lib.rs?

[RalfJung]

I don't know but @eddyb would. :)

[oli-obk]

oh, eh, implementing those may be very hard. I have no clue what's needed to implement them properly. There may be standards to read for edge cases and stuff.

[RalfJung]

FWIW, this is actually not the first Miri "intrinsic" that uses host floats; we have sin/cos/pow/... already implemented and they all use host floats right now (for lack of a softfloat implementation).

[oli-obk]

Well... the clean solution would be to add these functions to librustc_apfloat so we have actual soft impls that are the same everywhere

Wasn't meant to block this PR. My original suggestion to just round in the test still stands.

[RalfJung]

Actually we even already have the macro for that in tests/run-pass/intrinsics-math.rs.

[kungfukennyg]

Okay I moved my test cases to the pre-existing intrinsics-math.rs and modified to use the assert_approx_eq macro.

Edit: Looks like the windows builds aren't happy.

[RalfJung]

Looks like this is called _hypot on Windows, so maybe just add that as an alternative case here?

[RalfJung]

As announced before, this ran into the recent floating point changes, so now it does not build any more. I'm afraid I'll have to ask you to rebase. Also see rust-lang/rust#61673 and #764.

[kungfukennyg]

Okay no worries. I've done the rebase, now I need some guidance on what to do next. rustc_apfloat doesn't yet have functions for cbrt and hypot.

[RalfJung]

Right, so please copy-paste what sin and friends do to convert to host-floats (including copying the FIXME), and then just call some host implementation like you did before.

[kungfukennyg]

Okay I see, thanks!

[RalfJung]

Forgot to add a link to that code, here it is.

[kungfukennyg]

Should I move the cbrt and hypot match arms fromfn_call.rs to the others you've just linked in intrinsics.rs? That seems like the more fitting place.

[RalfJung]

No, "intrinsics.rs" is for intrinsics and "fn_call" is for emulating C functions.

[kungfukennyg]

Okay I see.

[RalfJung]

Yes this looks good. :) Let's see what CI says.

[RalfJung]

CI is happy. :D Thanks a lot!