-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scrutinize hash functions: << precedence often misused #1267
Comments
Fixed in @6c95e40 |
bjorn3
pushed a commit
to bjorn3/rust
that referenced
this issue
Aug 24, 2022
Cranelift 0.87 now supports lowering `fma` as a libcall on x86 [0]. With 0.88 enabling the native x86 instruction under the `has_fma` flag. aarch64 and s390x already support this as a native instruction, so it's nice that we emit it for those. We can't lower the SIMD version using the `fma` instruction since the lowering can fail if the x86 `has_fma` flag is not enabled. Cranelift doesn't yet know how to fallback for these cases [0]: bytecodealliance/wasmtime@709716b
celinval
pushed a commit
to celinval/rust-dev
that referenced
this issue
Jun 4, 2024
…#1267) * Add s2n-quic as a submodule * Add a script for running performance tests * Add a CI workflow for running performance tests
Kobzol
pushed a commit
to Kobzol/rust
that referenced
this issue
Dec 30, 2024
…lang#1267) rust-lang#91207 updates the coverage mapping format to Version 5 or 6, depending on the built-in version of LLVM (12 or 13, respectively). This change updates the dev guide to match the recent changes.
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 2, 2025
…lang#1267) rust-lang#91207 updates the coverage mapping format to Version 5 or 6, depending on the built-in version of LLVM (12 or 13, respectively). This change updates the dev guide to match the recent changes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found that many hash functions in rustc follow this template:
but by the order of precedence this yields
foo << (16u + bar)
, almost certainly not what was intended. This interacts quite poorly with our hash tables which prefer low-order bits to not be all 0. We need to search through the code and check for similar problems, then close this bug.The text was updated successfully, but these errors were encountered: