* Cleanup the argument handling logic to allow for optional arguments.
* Add a filter for which `llvm_target` to process.
* Switch to using a threadpool, needed for skipping llvm targets cleanly
and better distributes the work.
* Remove a seemingly useless piece of logic. I re-ran the script and it gave identical outputs.
Uses the non rational solution of a quadratic, I made it work up to 256
bits, added Mathematica code in case anyone wants to verify the magic
constant.
integers between sizes 3...15 were affected by fatal bias, it is best to
make them pass through the generic solution.
Thanks to RetroDev256 & Andrew feedback.
In the parent commit, I handled odd bit sizes by upcasting and
truncating. However it seems the else branch is intended to handle
those cases instead, so this commit reverts that behavior.
also
* allow signed ints, simply bitcast them to unsigned
* handle odd bit sizes by upcasting and then truncating
* naming conventions
* remove redundant code
* better use of testing API
Before, the default bit mixer was very biased, and after a
lot of searching it turns out that selecting a better solution is hard.
I wrote a custom statistical analysis taylored for bit mixers in order
to select the best one at each size (u64/u32/u16), compared a lot of
mixers, and packaged the best ones in this commit.
It wasn't immediately clear from the implementation whether passing
zero-length memory to free() was undefined behavior or intentionally
supported. Since ArrayList and other core data structures rely on
this behavior working correctly, this should be explicitly documented
as part of the public API contract.
And make the initialization less error prone by removing a default for
iter, which is required for a functional parser
std: Add a brief doc comment for `std.fmt.Parser`
Previously, stepping from the single statement within the loop would
always exit the loop because all of the code unrolled from the loop is
associated with the same line and treated by the debugger as one line.
/home/alexrp/.cache/zig/b/18236e302af25e3fb99bc6a232ddc447/builtin.zig:6:5: error: TODO (SPIR-V): Implement unsigned composite int type of 64 bits
pub const zig_backend = std.builtin.CompilerBackend.stage2_spirv64;
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is necessary since isGnuLibC() is true for hurd, so we need to be able to
represent a glibc version for it.
Also add an Os.TaggedVersionRange.gnuLibCVersion() convenience function.
Signed-off-by: Brian Cain <bcain@quicinc.com>
Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Co-authored-by: Alex Rønne Petersen <alex@alexrp.com>
The tool will now skip over undefined symbols. These can only occur as a result
of building musl without compiler-rt, i.e. -rtlib=none. Thanks to this, it's no
longer necessary to patch Zig's compiler-rt, nor is it necessary to maintain a
symbol blacklist.
See the updated instructions here: https://github.com/ziglang/zig/wiki/Updating-libc#updating-the-libcs-file
Additionally, the tool now produces slightly more compact output by recognizing
symbols that are defined for a single arch, for a family of arches, or only for
arches using 32-bit or 64-bit time as their primary ABI.
Finally, the tool now supports all architectures that we can emit code for, with
the single exception of x86_64-linux-muslx32. (x32 currently fails with a ton of
relocation errors, leading me to believe that it might be an LLVM or LLD bug.)
The `if (@sizeOf(T) == 0) return true;` check simply doesn't work for a number
of cases so that is removed and changed into `@sizeOf(T) != 0` and then
used in the `eqlBytes` check chain to make comparing `enum{}`s possible.
The rest special-cases for comptime-only types and undefined to make
those comparisons possible as well.
Fixes#19929
They way OpenSSH does key derivation to protect keys using a password
is not the standard PBKDF2, but something funky, picking key material
non-linearly.
* std.crypto.aes: introduce AES block vectors
Modern Intel CPUs with the VAES extension can handle more than a
single AES block per instruction.
So can some ARM and RISC-V CPUs. Software implementations with
bitslicing can also greatly benefit from this.
Implement low-level operations on AES block vectors, and the
parallel AEGIS variants on top of them.
AMD Zen4:
aegis-128x4: 73225 MiB/s
aegis-128x2: 51571 MiB/s
aegis-128l: 25806 MiB/s
aegis-256x4: 46742 MiB/s
aegis-256x2: 30227 MiB/s
aegis-256: 8436 MiB/s
aes128-gcm: 5926 MiB/s
aes256-gcm: 5085 MiB/s
AES-GCM, and anything based on AES-CTR are also going to benefit
from this later.
* Make AEGIS-MAC twice a fast
* crypto.keccak.State: don't unconditionally permute after a squeeze()
Now, squeeze() behaves like absorb()
Namely,
squeeze(x[0..t]);
squeeze(x[t..n)); with t <= n
becomes equivalent to squeeze(x[0..n]).
* keccak: in debug mode, track transitions to prevent insecure ones.
Fixes#22019
