-
Notifications
You must be signed in to change notification settings - Fork 103
Add tests against MPFR for ilogb
and ilogbf
#398
Conversation
cabf548
to
fad3f86
Compare
crates/libm-test/src/mpfloat.rs
Outdated
|
||
fn run(this: &mut Self::MpTy, input: Self::RustArgs) -> Self::RustRet { | ||
this.assign(input.0); | ||
this.get_exp().unwrap_or(i32::MIN) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, thanks. Updated this and added your explanation as a comment.
fad3f86
to
5b76943
Compare
ilogb
and ilogbf
ilogb
and ilogbf
// one to scale the significand to `1.0 <= |m| < 2.0`. | ||
this.get_exp().map(|v| v - 1).unwrap_or_else(|| { | ||
if this.is_infinite() { | ||
i32::MAX |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some microcontrollers have 16-bit c_int
(AVR? icr if the rust version does but iirc some C compilers do), so you should probably use c_int
here rather than i32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or are you assuming the tests never are compiled on 16-bit c_int
targets? (since idk if mpfr can compile for those targets)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this isn't accurate but the source needs to be fixed for this and other routines that should be c_int
Lines 1 to 5 in ff15e46
const FP_ILOGBNAN: i32 = -1 - 0x7fffffff; | |
const FP_ILOGB0: i32 = FP_ILOGBNAN; | |
#[cfg_attr(all(test, assert_no_panic), no_panic::no_panic)] | |
pub fn ilogb(x: f64) -> i32 { |
I doubt MPFR would build on 16-bit targets, I can't even get it to compile for i586 or any Windows targets (might be possible but I haven't spent a lot of time here yet). I have a branch that serializes test input and MPFR results to a file and can run tests against that, that is my loose plan for how to get coverage on these targets without building mpfr/musl.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, upstream mpfr claims to compile on i686 mingw and debian has a version for "i386", so i expect it to work for those; AVR is more questionable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MinGW should be possible, I just ran into a lot of difficulty getting the correct dependencies and paths set up via msys on GHA. I guess I need to revisit i586; I thought there were build failures but it looks like it is our implementation that is dropping the sign #404. Probably related to how we unconditionally use x87 https://github.com/rust-lang/libm/blob/ff15e465d6d4beb81e686fdfdeb40388b474bb3e/src/math/arch/i586.rs.
5b76943
to
1b52164
Compare
No description provided.