Juniper Tyree
Juniper Tyree
To test, you can just create an e.g. standard normal array to reproduce.
The backtrack we get inside WASM looks like this (frames 1-9) are inside zfp, the others in my Rust wrapper: Caused by: 0: error while executing at wasm backtrace: 0:...
I opened https://github.com/juntyr/zfp-wasm-bug where I tested zfp on x86. It took me a lot of iterations but in the end, here are my results: The bug was still in zfp_stream_maximum_size....
These results now came when compiling to x86 with gcc on alpine, so I doubt that it's a compiler issue. But I also wonder why every operand had to be...
> I also noticed that the encoded sizes are still different on 32bit vs 64bit: That was my bad, because I'm using random test data the variance in the exact...
I reduced the widening to ``` maxsize = ((ZFP_HEADER_MAX_BITS + ((bitstream_size)blocks) * maxbits + stream_word_bits - 1) & ~(((bitstream_size)stream_word_bits) - 1)) / CHAR_BIT; ``` So we need an additional widening...
> Ah, this indeed is necessary as the integral promotion does not extend the right-hand-side operand of `&` with one-bits, as needed to keep all the MSBs in the 64-bit...
> I pushed some changes to `develop` that implement `round_up` via "C templates." This hopefully takes care of any remaining bugs. I can confirm that the latest commit on develop...
ZFP now works on wasm32 with large datasets - the fix is confirmed! Thank you again for your help!
CC @SF-N