Latest libm 0.2.13 is failing during LTO

[jorge-ortega]

As of a few days ago, our kernel crates fail to build in CI with the following error (plus some additional logging I added)

error: failed to parse bitcode for LTO module libm.9303cbbb082352b3-cgu.09: Invalid cast (Producer: 'LLVM7.0.1' Reader: 'LLVM 7.0.1')

Turns out there was a new release for libm on April 22. I originally wasn't able to repro this, as the Cargo.lock file I had was set to libm 0.2.11. After regenerating my lock file, which updates to libm 0.2.13, I'm able to repro this in on windows and ubuntu 24.

I have yet to figure out what changed in libm that's causing the codegen to fail during LTO. In the meantime, the best work around seems to be lock libm to 0.2.11:

[[package]]
name = "libm"
version = "0.2.11"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8355be11b20d696c8f18f6cc018c4e372165b1fa8126cef092399c9951984ffa"

[jorge-ortega]

The nvvvm codegen attempts to override libm functions to use libdevice functions when it finds a matching intrinsic. The override logic assumes the C standard library names that matches the parameters it takes: fmodf would take floats, while fmod would take doubles.

libm 0.2.13 now uses a generic core implementation for some of the functions it provides. This introduces multiple functions with the same name (e.g fn fmod(f64, f64) and fn fmod<F : Float>(F, F)). When the codegen is given the monomorphized function, like fmod<f32>, it confuses it for fmod that takes f64 and attempts to build a call to __nv_fmod(f64, f64). Because the types don't match, it tries to insert a bitcast from f32 to f64, which is an invalid cast.

fmod is just one case of this, but there are several other generic functions in libm now that could cause the same error.