* Add tagName to Value which behaves like @tagName.
* Add hashUncoerced to Value as an alternative to hash when we want to
produce the same hash for value that can coerce to each other.
* Hash owner_decl instead of module_fn in Sema.instantiateGenericCall
since Module.Decl.Index is not affected by ASLR like *Module.Fn was,
and also because GenericCallAdapter.eql was already doing this.
* Use Value.hashUncoerced in Sema.instantiateGenericCall because
GenericCallAdapter.eql uses Value.eqlAdvanced to compare args, which
ignores coersions.
* Add revealed missing cases to Value.eqlAdvanced.
Without these changes, we were breaking the hash contract for
monomorphed_funcs, and were generating different hashes for values that
compared equal. This resulted in a 0.2% chance when compiling
self-hosted of producing a different output, which depended on
fingerprint collisions of hashes that were affected by ASLR. Normally,
the different hashes would have resulted in equal checks being skipped,
but in the case of a fingerprint collision, the truth would be revealed
and the compiler's behavior would diverge.
- the meaning of packed structs changed in zig 0.10. adjust accordingly.
Use "extern struct" for the cases that directly map to C structs.
- Add new type info kinds, like enum64 and DeclTag
- change the Type enum to use the canonical names from libbpf.
This is more predictable when comparing with external BPF
documentation (than invented synonyms that need to be guessed)
This service stopped working two days ago for unknown reasons. Until it
is determined how to get it working again, or we switch to a different
CI provider for aarch64, this CI test coverage is disabled so that
we can continue to use the CI for other targets.
* crypto.core.aes: process 6 block in parallel instead of 8 on aarch64
At least on Apple Silicon, this is slightly faster than 8 blocks.
* AES: add parallel blocks for tigerlake, rocketlake, alderlake, zen3
...instead of hard-coding it to 20.
- This is consistent with the ChaCha implementation
- NaCl and libsodium, that this API is designed to interop with,
also support 8 and 12 round variants. The 12 round variant, in
particular, provides the same security level as the 20 round variant,
but is obviously faster.
- scrypt currently uses its own non optimized version of Salsa, just
because it use 8 rounds instead of 20. This will help remove code
duplication.
No behavior nor public API changes. The Salsa20 and XSalsa20 still
represent the 20-round variant.
Empirically, this `AutoHashMapUnmanaged` -> `AutoArrayHashMapUnmanaged`
change fixes all non-determinism in `ReleaseFast` build artifacts.
Closes#12183
If the noise parameter was null, we didn't use any noise at all.
We unconditionally generated random noise (`noise2`) but didn't use it.
Spotted by @cryptocode, thanks!
On platforms where c_longdouble is 128-bits, interop with C code
is simplified by making f128 match the alignment of c_longdouble.
I intended to make this change as part of #13257, but I missed this
part.
When a number of bytes to be allocated is so great that alignForward()
is not possible, return `error.OutOfMemory`.
Companion commit to 3f3003097cbf5a6ad9e0dfc29b2cafbe2e35dded.
This reverts commit 06310e3d4eb47fed88b175891cb5865bb050f020, reapplying
commit a430630002bf02162ccbf8d3eb10fd73e490cefd.
I deeply apologize to @moosichu and those affected by this bug. The
original fix was actually fine. When I reverted it, I misremembered
how the Cache API works. I thought the fix was going to introduce
nondeterminism into the hash, but I forgot that the order of files in
the manifest doesn't actually matter when checking for a cache hit.
Actually, it does matter a little bit. This fix has a subtle downside
which is that it does introduce the possibility of false negatives when
checking for cache hits of 2+ iterations ago. For example, if the code
goes from "foo", to "bar", and then back to "foo", it may look like a
cache miss when it should have been a hit because 2 iterations ago the
code was the same. However, this is an uncommon use case, and all it
does is cause a bit of wasted time and disk space. That said, my
suggestion from earlier still applies and would be a nice follow-up
enhancement to this fix:
The proper solution to this is to, in whole cache mode, append the hash
inputs to some data structure, and then after the compilation is
complete, do some kind of sorting on the hash inputs so that they will
be the same order every time, then apply them in sequence. No lock on
the Cache object is needed for this scheme.
closes#11063
