| Age | Commit message (Collapse) | Author |
|---|
|
This should be irrelevant, but some toolchains will not accept movd with 64-bit arguments.
|
|
|
|
|
|
|
|
https://github.com/BLAKE3-team/BLAKE3/pull/24
|
|
|
|
|
|
|
|
|
|
add blake3_version(void) / BLAKE3_VERSION_STRING
|
|
related discussion here: https://github.com/BLAKE3-team/BLAKE3/issues/130
|
|
|
|
fix disabled-optimization -Wall -Werror
|
|
|
|
patch by Samuel Neves ( https://github.com/sneves )
if you tried to compile blake3_dispatch.c with
-Wall -Werror -DBLAKE3_NO_SSE2 -DBLAKE3_NO_SSE41 -DBLAKE3_NO_AVX2 -DBLAKE3_NO_AVX512
something like this would happen:
hans@xDevAd:~/projects/BLAKE3/c$ gcc -O0 -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 -DBLAKE3_NO_SSE2 -DBLAKE3_NO_SSE41 -DBLAKE3_NO_AVX2 -DBLAKE3_NO_AVX512 -Wall -Wextra -Wpedantic -Werror
blake3_dispatch.c: In function ‘blake3_compress_in_place’:
blake3_dispatch.c:139:26: error: unused variable ‘features’ [-Werror=unused-variable]
139 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
blake3_dispatch.c: In function ‘blake3_compress_xof’:
blake3_dispatch.c:167:26: error: unused variable ‘features’ [-Werror=unused-variable]
167 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
blake3_dispatch.c: In function ‘blake3_hash_many’:
blake3_dispatch.c:195:26: error: unused variable ‘features’ [-Werror=unused-variable]
195 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
blake3_dispatch.c: In function ‘blake3_simd_degree’:
blake3_dispatch.c:244:26: error: unused variable ‘features’ [-Werror=unused-variable]
244 | const enum cpu_feature features = get_cpu_features();
| ^~~~~~~~
cc1: all warnings being treated as errors
|
|
|
|
|
|
Changes since 0.3.6:
- BUGFIX: The C implementation was incorrect on big endian systems for
inputs longer than 1024 bytes. This bug affected all previous versions
of the C implementation. Little endian platforms like x86 were
unaffected. The Rust implementation was also unaffected.
@jakub-zwolakowski and @pascal-cuoq from TrustInSoft reported this
bug: https://github.com/BLAKE3-team/BLAKE3/pull/118
- BUGFIX: The C build on x86-64 was producing binaries with an
executable stack. @tristanheaven reported this bug:
https://github.com/BLAKE3-team/BLAKE3/issues/109
- @mkrupcale added optimized implementations for SSE2. This improves
performance on older x86 processors that don't support SSE4.1.
- The C implementation now exposes the
`blake3_hasher_init_derive_key_raw` function, to make it easier to
implement language bindings. Added by @k0001.
|
|
This will let us add big endian testing to CI for our C code. (We were
already doing it for our Rust code.)
This is adapted from test_vectors/cross_test.sh. It works around the
limitation that the `cross` tool can't reach parent directories. It's an
unfortunate hack, but at least it's only for testing. It might've been
less hacky to use symlinks for this somehow, but I worry that would
break things on Windows, and I don't want to have to add workarounds for
my workarounds.
|
|
Kudos to @pascal-cuoq and @jakub-zwolakowski from TrustInSoft for
catching these bugs.
Original report: https://github.com/BLAKE3-team/BLAKE3/pull/118
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/BLAKE3-team/BLAKE3/blob/master/b3sum/what_does_check_do.md
|
|
|
|
|
|
|
|
|
|
|
|
C: Add blake3_hasher_init_derive_key_len
|
|
|
|
|
|
|
|
|
|
Samuel noticed that rustc seems to assume (incorrectly?) that all i686
targets support SSE2, but it doesn't make that assumption for i586.
|
|
It will be very rare that this actually executes, but we should include
it for completeness.
|
|
This is quite hard to trigger, because SSE2 has been guaranteed for a
long time. But you could trigger it this way:
rustup target add i686-unknown-linux-musl
RUSTFLAGS="-C target-cpu=i386" cargo build --target i686-unknown-linux-musl
Note a relevant gotcha though: The `cross` tool will not forward
environment variables like RUSTFLAGS to the container by default, so if
you're testing with `cross` you'll need to use the `rustc` command to
explicitly pass the flag, as I've done here in ci.yml. (Or you could
create a `Cross.toml` file, but I don't want to commit one of those if I
can avoid it.)
|
|
|
|
|
|
Add SSE2 implementations
|
|
Use statically calculated ~mask. This reduces the number of moves and registers necessary at the expense of an extra memory load. This is probably a good trade-off since we are not bound by memory uops in this loop.
|
|
This enables pretty printing via `{:#?}`. The normal style for `{:?}` is
kept exactly the same.
|
|
Use punpckl{,q}dq instead of pinsrw.
|
|
This simplifies the operation by removing the need to use blendvps at all.
|
|
blake3_hasher_init_derive_key_len is an alternative version of
blake3_hasher_init_derive_key which takes the context and its
length as separate parameters, and not together as a C string.
The motivation for this addition is making it easier for
bindings to this C library to call this function without
having to first copy over the context bytes just to add
one 0x00 byte at the end.
Notice that contrary to blake3_hasher_init_derive_key,
blake3_hasher_init_derive_key_len allows the inclusion of a
0x00 byte in the context. Given the rules about context string
selection, this byte is unlikely to be used as part of a context
string. But if for some reason it is ever given, it will be
included in the context string and processed like any other
non-alphanumeric byte would. For compatibility with
blake3_hasher_init_derive_key, bindings should still check for
the absence of 0x00 bytes.
|
|
|
|
Use _mm_and_si128 and _mm_cmpeq_epi16 rather than expensive multiplication _mm_mullo_epi16 with _mm_srai_epi16 that compiler may not be able to optimize.
|
|
MSVC returns "error A2006:undefined symbol : FFFFFFFFH", so use 0FFFFFFFFH instead. Also use 0 prefix for 0H to align things.
|
