SSSE3 is indicated by bit 9 of ECX, not bit 0, which indicates the
presence of SSE3.
There are very few CPUs in use affected by this bug; SSE3 was part of
the Prescott new instructions, introduced in the later Pentium 4 chips,
whereas SSSE3 was introduced in Intel's Core 2 and AMD's Bulldozer. This
leaves a few Pentium 4 and Athlon 64 models that will potentially run an
illegal pshufb or pblendw.
Add a warning to stderr at the end similar to other *sum utilities when --check is used and some files failed verification.
At least the last part of the comment above check_one_checkfile seemed to be incorrect so I removed that comment.
Fixes #283
Changes since 1.3.2:
- Fix incorrect output from AVX-512 intrinsics under GCC 5.4 and 6.1 in
debug mode. This bug was found in unit tests and probably doesn't
affect the public API in practice. See
https://github.com/BLAKE3-team/BLAKE3/issues/271.
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/271.
The `_mm512_cmp_epu32_mask` intrinsic is broken under GCC 5.4 and 6.1.
This led to incorrect output in the AVX-512 implementation when building
with intrinsics instead of assembly. This fix is a simplified version of
Samuel's proposed fix here:
f10816e857 (commitcomment-90742995)
I'm adding the i32::MAX test case here because I personally screwed it
up while I was working on
https://github.com/BLAKE3-team/BLAKE3/issues/271. The correct
implementation of the carry bit is the ANDNOT of old high bit (1) and
the new high bit (0). Using XOR instead of ANDNOT gives the correct
answer in the overflow case, but it also reports an incorrect "extra"
overflow when the high bit goes from 0 to 1.
Changes since 1.3.1:
- Dependency updates only. This includes updating Clap to v4, which
changes the format of the `b3sum --help` output. The new MSRV is
1.59.0 for `blake3` and 1.60.0 for `b3sum`. Note that this project
doesn't have any particular MSRV policy, and we don't consider MSRV
bumps to be breaking changes.
v6.4.0 has a bug where invalid UTF-16 filenames fail a debug_assert on
Windows. See https://github.com/dylni/os_str_bytes/issues/14. The vast
majority of b3sum users should be running a binary built in release mode
and shouldn't be affected by this. This lockfile change fixes our CI,
but note that `cargo install` doesn't respect lockfiles by default
(without --locked), so anyone running a debug binary against invalid
Windows filepaths (very rare) will still need to wait for an upstream
patch release.
