ppc64/s390x assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)
#38891
Assignees
Labels
P-high
High priority
regression-from-stable-to-beta
Performance or correctness regression from stable to beta.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
This looks the same as or similar to #38177 which was marked fixed last month. |
|
I'm also experiencing this on an arch-i686 machine. There's no graphical environment installed on the machine yet, so it's difficult for me to post a backtrace from it. |
|
I am quite sure this is fixed in i686 - are you using the latest nightly? |
|
Ah, just realize my build was being pinned to |
|
Just to stay in sync, I updated my ppc64 and it still fails. However, ppc64le is fine, so perhaps there are some little-endian assumptions lingering after the #38177 fix? BAD: GOOD: |
|
This also fails the same way on s390x, so it seems pretty likely to be an endianness issue. |
cuviper
changed the title
assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)assertion failed: eps.windows(2).all(|w| w[0].cmp(self, &w[1]) != Ordering::Greater)
arielb1
added
the
regression-from-stable-to-beta
arielb1
added a commit
to arielb1/rust
that referenced
this issue
Jan 10, 2017
Like many hash functions, the blake2 hash is mathematically defined on a sequence of 64-bit words. As Rust's hash interface operates on sequences of octets, some encoding must be used to bridge that difference. The Blake2 RFC (RFC 7693) specifies that: Byte (octet) streams are interpreted as words in little-endian order, with the least-significant byte first. So use that encoding consistently. Fixes rust-lang#38891.
nikomatsakis
added
T-compiler
bors
added a commit
that referenced
this issue
Jan 11, 2017
Use little-endian encoding for Blake2 hashing on all architectures Like many hash functions, the blake2 hash is mathematically defined on a sequence of 64-bit words. As Rust's hash interface operates on sequences of octets, some encoding must be used to bridge that difference. The Blake2 RFC (RFC 7693) specifies that: ``` Byte (octet) streams are interpreted as words in little-endian order, with the least-significant byte first. ``` So use that encoding consistently. Fixes #38891. Beta-nominating since this is a regression since 1.15. r? @michaelwoerister
cuviper
pushed a commit
to cuviper/rust
that referenced
this issue
Jan 12, 2017
Like many hash functions, the blake2 hash is mathematically defined on a sequence of 64-bit words. As Rust's hash interface operates on sequences of octets, some encoding must be used to bridge that difference. The Blake2 RFC (RFC 7693) specifies that: Byte (octet) streams are interpreted as words in little-endian order, with the least-significant byte first. So use that encoding consistently. Fixes rust-lang#38891.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While looking into #37996 on Fedora 25 ppc64, I hit a rustc assertion building rust-encoding. The same nightly version is fine on Fedora 25 x86_64. Stable and beta ppc64 are also fine, barring the linker problems from that former issue.
Here's the backtrace from the first occurrence:
The text was updated successfully, but these errors were encountered: