Closed mlund closed 1 year ago
Adding panic_immediate_abort
to .cargo/Config.toml
fixes the issue also for optimization levels s
and z
:
[unstable]
build-std = ["core", "alloc"]
build-std-features = ["panic_immediate_abort"]
Thanks to @mrk-its!
Nice! I haven't been able to test this yet since the computer containing the toolchain got replaced, and it's not zero effort to rebuild the entire thing. But I'll try again once I have some time.
Yep, it requires some patience to build the toolchain :-) I just use the Docker images on Dockerhub (
mrkits/rust-mos
for x86 andmikaellund/rust-mos
for arm)
Did a quick test and I can confirm it's working now! I did see some strings in the final release binary related to gdb
, oddly enough, but I didn't have the time to dive into that.
It looks it works with last rust-mos build (even without panic_immediate_abort hack), closing.
This code runs as expected, but is slow:
whereas this (significantly faster) version never enters the loop as if the cartesian product is empty:
This is tested with the rust-mos docker image (Oct. 9, 2022) and itertools 0.10.5. The
.iter()
variant used to work (summer 2022), but I still get the unexpected behavior when rolling back the itertools version. The issue persists for both andc64
,mega65
andsim
targets.Update: The issue appear when using optimization level
s
orz
. For level2
and3
the.iter()
version works!