can't call foreign functions from cmath (libm)

[cuviper]

I just tried cargo miri test on the various num crates. I got pretty far, but I was stopped by errors on foreign function calls from std::sys::cmath, which come from libm on unix platforms. For example:

num-complex:

error[E0080]: constant evaluation error: can't call foreign function: hypot
   --> /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/f64.rs:533:18
    |
533 |         unsafe { cmath::hypot(self, other) }
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^^ can't call foreign function: hypot
    |

num-integer:

   --> /home/jistone/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd/f64.rs:513:18
    |
513 |         unsafe { cmath::cbrt(self) }
    |                  ^^^^^^^^^^^^^^^^^ can't call foreign function: cbrt
    |

[oli-obk]

These should be fairly easy to do by adding new match arms to

miri/src/fn_call.rs

Line 464 in 95a842b

"strlen" => {

and following the implementation strategies of the intrinsics

[kungfukennyg]

Hi, I'm interested in attempting this issue. Can you @oli-obk expand on what implementing the match arms would entail? I'm guessing I'd just find what the two functions causing issues (cbrt, hypot) are meant to do and implement that functionality?

[oli-obk]

@kennethbgoodin after implementing cbrt and hypot you may hit more such errors when running Miri on num. But starting with those two is a good plan.

Yes, essentially reimplement that functionality. Since we don't care too much about floating point correctness, you can actually just read a float and run the appropriate function by making Miri depend on the cmath crate and calling the function from the cmath crate.

[cuviper]

FWIW, cmath is not a crate here, just a std module of extern declarations. Can Miri just call that natively itself? (Or perhaps call f64::cbrt to end up there.)

[kungfukennyg]

It doesn't look like I can access std::f64::cbrt from within miri, failing to compile trying to use that.

[cuviper]

It would be a method of the f64 primitive type, not the std::f64 module.

[kungfukennyg]

oh, doi. Thanks!

[kungfukennyg]

What would be the best way to test? Should I build the compiler, add it to my toolchain. and then do cargo miri test on the num crates?

[RalfJung]

Yeah, I have a toolchain stage2 pointing to build/x86_64-unknown-linux-gnu/stage2. Then I ./x.py build src/rustc in the rustc dir, switch to the Miri dir, rustup override set stage2 and finally ./miri install.

Also see the relevant section in the Miri README.

[RalfJung]

I'd also recomment writing a testcase that does not depend on num but calls these methods directly. We'll want that for Miri's test suite anyway, and then you can just ./miri run <file>.rs, which is easier than dealing with cargo miri. (Do ./miri run-debug if you want compilation to be faster.)

[oli-obk]

maybe we can convice the num authors to run miri from rustup in their CI?

[cuviper]

I am a num author, so yes, this is something I would like in CI.