When I try to use Num.sqrt or Num.sqrtChecked or Num.pow 1/2 I get some variant of
thread 'main' panicked at 'internal error: entered unreachable code: Unrecognized dec binary operation: NumPow', crates/compiler/gen_llvm/src/llvm/lowlevel.rs:2386:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
am I doing something wrong or is this just not built out yet?
powInt seems to work just fine though.
Full stacktrace doesn't seem super useful
stack backtrace:
0: 0x10381d9fc - __mh_execute_header
1: 0x102dd586c - __mh_execute_header
2: 0x1038196a4 - __mh_execute_header
3: 0x10381d814 - __mh_execute_header
4: 0x103821550 - __mh_execute_header
5: 0x1038212fc - __mh_execute_header
6: 0x103821b34 - __mh_execute_header
7: 0x103821920 - __mh_execute_header
8: 0x1038204bc - __mh_execute_header
9: 0x1038216d4 - __mh_execute_header
10: 0x106233570 - __ZN4llvm15SmallVectorBaseIyE8grow_podEPvmm
11: 0x103258a48 - __mh_execute_header
12: 0x103222f90 - __mh_execute_header
13: 0x103227418 - __mh_execute_header
14: 0x10322d7bc - __mh_execute_header
15: 0x103237c4c - __mh_execute_header
16: 0x103234f88 - __mh_execute_header
17: 0x10360029c - __mh_execute_header
18: 0x1030509cc - __mh_execute_header
19: 0x102f61ca0 - __mh_execute_header
20: 0x102f57fa4 - __mh_execute_header
21: 0x102f57fc8 - __mh_execute_header
22: 0x1038124fc - __mh_execute_header
23: 0x102f650f4 - __mh_execute_header```
This happens in roc test, roc run (with or without optimize), and in the repl
I thought we had caught all of these for our custom Dec
type, but I guess not. For now, you can use F32
or F64
as the type and that should workaround this
tracked in #6208
Oh awesome thanks for the quick unblock!
Last updated: Jul 06 2025 at 12:14 UTC