incorrect output from the SSE2 implementation under the `iSH` emulator

[bdbai]

I am using BLAKE3 on some exotic x86 platforms where the computation result is incorrect under default setup. Unfortunately, there seems no way to turn off any hardware accelerations without patching the source code. Would it be better if an cfg flag is exposed, say blake3_force_soft, which forces implementation to use Platform::Portable? The same approach has been used in RustCrypto crates such as aes.

[oconnor663]

We do have features for disabling SIMD, but they're not especially convenient to use, and we don't consider them stable. What happens if you enable no_sse2, no_sse41, no_avx2, and no_avx512?

the computation result is incorrect under default setup

That's concerning, could you say more about it?

[bdbai]

@oconnor663

We do have features for disabling SIMD, but they're not especially convenient to use, and we don't consider them stable. What happens if you enable no_sse2, no_sse41, no_avx2, and no_avx512?

Oops I overlooked the feature list. When I enable no_sse2 the result turns out to be correct. Thanks for the pointer!

the computation result is incorrect under default setup

That's concerning, could you say more about it?

The test program is a simple Cargo project with Cargo.toml

[package]
name = "test-blake3"
version = "0.1.0"
edition = "2024"

[dependencies]
# blake3 = { version = "=1.8.3", features = ["no_sse2"] }
blake3 = { version = "=1.8.3", features = [] }

and src/main.rs

fn main() {
    let hash1 = blake3::hash(b"foobarbaz");
    println!("{}", hash1);
}

compiled using toolchain 1.93.1 (083ac5135 2025-12-15) (latest stable) in an alpine Docker container targeting i686-unknown-linux-musl in release profile. Inside the container, the result seems correct.

5b55a19da117:~/test-blake3$ cargo run --release --target i686-unknown-linux-musl
   Compiling test-blake3 v0.1.0 (/home/bdbai/test-blake3)
    Finished `release` profile [optimized] target(s) in 0.35s
     Running `/home/bdbai/cargo-target/i686-unknown-linux-musl/release/test-blake3`
c09afee0c9f361fb61e5ff28a7739893de766fb470c5fa82b4e5e31de27fbad4

Then I copied the binary to the iSH terminal on my iPhone, which is the exotic platform I mentioned above. When executed, it shows a very different output.

Hence I am suspecting iSH having a faulty SSE2 implementation and it doesn't necessarily indicate a bug of blake3.

[oconnor663]

I wonder if it could also be a case like this: #206. Sometimes the calling convention is different in subtle ways on different platforms. I'd be curious whether the prefer_intrinsics or pure features have any effect here? (In the absence of AVX-512 support there isn't much of a difference between them.)

[oconnor663]

@tbodt if you have any interest in looking into this, here's a quick way (from this section of our readme) to build a C program that should also be able to repro:

$ git clone https://github.com/BLAKE3-team/BLAKE3
$ cd BLAKE3/c
$ gcc -O3 -o example example.c blake3.c blake3_dispatch.c blake3_portable.c \
    blake3_sse2_x86-64_unix.S blake3_sse41_x86-64_unix.S blake3_avx2_x86-64_unix.S \
    blake3_avx512_x86-64_unix.S
$ echo -n foobarbaz | ./example
c09afee0c9f361fb61e5ff28a7739893de766fb470c5fa82b4e5e31de27fbad4

(That's the expected correct answer, running on my machine.)

[sneves]

I'm not familiar with this iSH software, but it appears it is x86 only? That is, 32-bit x86.

The assembly routines target x86_64, so this is probably using the intrinsics code, as it wouldn't even link otherwise?

[oconnor663]

Ah my bad. The Rust build figures these things out automatically, and I think our CMake files might also, but if you want to compile C code by hand then this might be what you need (omitting the non-SSE2 files entirely this time):

gcc -O3 -DBLAKE3_NO_AVX512 -DBLAKE3_NO_AVX2 -DBLAKE3_NO_SSE41 -o example example.c blake3.c blake3_dispatch.c blake3_portable.c blake3_sse2.c

[bdbai]

Ah my bad. The Rust build figures these things out automatically, and I think our CMake files might also, but if you want to compile C code by hand then this might be what you need (omitting the non-SSE2 files entirely this time):

gcc -O3 -DBLAKE3_NO_AVX512 -DBLAKE3_NO_AVX2 -DBLAKE3_NO_SSE41 -o example example.c blake3.c blake3_dispatch.c blake3_portable.c blake3_sse2.c

Interestingly the c version gives the correct answer.

I wonder if it could also be a case like this: #206. Sometimes the calling convention is different in subtle ways on different platforms. I'd be curious whether the prefer_intrinsics or pure features have any effect here? (In the absence of AVX-512 support there isn't much of a difference between them.)

blake3 = { version = "=1.8.3", features = ["pure","prefer_intrinsics"] } or blake3 = { version = "=1.8.3", features = ["pure"] } both produced the same incorrect result.