Folkert de Vries

Reading over the other issue again, you could also try and see if disabling the `max-performance` feature helps at all.

That does seem very plausible, good investigative work! It might be a couple of days before I'll be able to look into this further.

I think https://github.com/trifectatechfoundation/zlib-rs/pull/449 should fix it, could someone check that?

I fixed those here https://github.com/rust-lang/stdarch/commit/e3ba06b17f9b6dd36ec6b4e6812bb295ab345eda, you can cherry-pick + squash that if you think that looks good.

https://developer.arm.com/architectures/instruction-sets/intrinsics/vmaxnmvq_f32 only mentions that it reduces using the maximum. Then looking at documentation for maximum operations, e.g. https://developer.arm.com/architectures/instruction-sets/intrinsics/vmaxnmq_f32 it says nothing but links to the instruction https://developer.arm.com/documentation/ddi0602/2025-06/SIMD-FP-Instructions/FMAXNM--vector---Floating-point-maximum-number--vector-- > Regardless of...

An additional complication is that we do want our portable intrinsic to optimize well, so ideally it would actually map to the instruction that the hardware has. We verify that...

Can you isolate the issue into a godbolt.org snippet? I vaguely remember there is some `full-fp16` flag though I can't find much about it now.

using `-fpu=neon-fp16` helps a bit. also I don't really see why these changes cause this issue? was this code not generated before?

it also isn't great with the native repl ``` » 1 / 0 This Roc code crashed with: "Decimal division by 0!" : Frac * ``` much of the code...