I was looking at the failed tests for the isApproxEq PR. Do I need to add a 32bit implementation here in ./gen_dev/src/generic64/mod.rs
?
fn build_num_abs(&mut self, dst: &Symbol, src: &Symbol, layout: &InLayout<'a>) {
match self.interner().get_repr(*layout) {
LayoutRepr::Builtin(Builtin::Int(IntWidth::I64 | IntWidth::U64)) => {
let dst_reg = self.storage_manager.claim_general_reg(&mut self.buf, dst);
let src_reg = self.storage_manager.load_to_general_reg(&mut self.buf, src);
ASM::abs_reg64_reg64(&mut self.buf, dst_reg, src_reg);
}
LayoutRepr::Builtin(Builtin::Float(FloatWidth::F64)) => {
let dst_reg = self.storage_manager.claim_float_reg(&mut self.buf, dst);
let src_reg = self.storage_manager.load_to_float_reg(&mut self.buf, src);
ASM::abs_freg64_freg64(&mut self.buf, &mut self.relocs, dst_reg, src_reg);
}
x => todo!("NumAbs: layout, {:?}", x),
}
}
That's for the dev backend
I guess so. That or just ignore the dev backend for now
What is the status for gen_llvm
?
ignoring the dev backend means isApproxEq
does not work in the repl. So I think that we do need an implementation for it
I've implemented it here https://github.com/roc-lang/roc/pull/6401
I merged your changes into my branch approxEq, but it still gets this error when running cargo test --release
(signal: 11, SIGSEGV: invalid memory reference)
so this is likely an error in your changes then? you can check this by using e.g. cargo nextest-gen-llvm
(note nextest
instead of test
this only works for the gen tests but I'm assuming that is where the error is
Since I saw f32_abs was merged to main, I went ahead and made a new feature branch based on updated main with just the isApproxEq implementation.
This PR should be ready for review and should pass the tests now.
https://github.com/roc-lang/roc/pull/6421
Last updated: Jul 06 2025 at 12:14 UTC