Regression in cross-compiling from 64 -> 32 bit #36793
Comments
alexcrichton
added
I-nominated
regression-from-stable-to-nightly
eddyb
added
the
E-easy
TypeIdHasher: hash usize as u64 Fixes rust-lang#36793.
TypeIdHasher: hash usize as u64 Fixes #36793.
|
Is this related? https://travis-ci.org/BurntSushi/ripgrep/jobs/163366626 (Cross compiling |
|
@BurntSushi I'd think that you're experiencing exactly this issue, although I'm not sure what to make of these warnings (and if they are even important): |
|
This bug is affecting the current beta: 1.13.0.beta.1. Can the fix be backported? This bug may affect bootstrapping the compiler, I think; that beta is (or will soon be) the current stage0 (?). |
|
It looks like this is also still affecting nightly: |
|
@eddyb thoughts about any more vectors where a |
|
No idea. Do we do anything special about hashing slices? IIRC string slices get invalid Unicode separators, but what about otherl slices? Not that I can think of a place whwre we would use slices. |
|
Looks like |
|
|
I'm working on a patch |
alexcrichton
removed
the
E-easy
|
Maybe we can just hash all i,usizes as i,u64s in the Hasher implementation? |
|
Indeed! I first tried to just panic and audit locations, but turns out there's a bunch, so I'm just auto-widening those to i/u64 now |
|
Ok, I've confirmed that compiling hello world from 64 -> 32 works with #36866 |
|
@alexcrichton How can that be when you haven't fixed the symbol case? |
In another attempt to fix rust-lang#36793 this commit attempts to head off any future problems by adding a custom `WidentUsizeHasher` which will widen any hashing of `isize` and `usize` to a `u64` as necessary. This obviates the need for a previous number of `as u64` annotations and will hopefully protect us against future problems here. Closes rust-lang#36793 (hopefully)
rustc: More fixes for arch-independent hashing In another attempt to fix #36793 this commit attempts to head off any future problems by adding a custom `WidentUsizeHasher` which will widen any hashing of `isize` and `usize` to a `u64` as necessary. This obviates the need for a previous number of `as u64` annotations and will hopefully protect us against future problems here. Closes #36793 (hopefully)
In another attempt to fix rust-lang#36793 this commit attempts to head off any future problems by adding a custom `WidentUsizeHasher` which will widen any hashing of `isize` and `usize` to a `u64` as necessary. This obviates the need for a previous number of `as u64` annotations and will hopefully protect us against future problems here. Closes rust-lang#36793 (hopefully)
In another attempt to fix rust-lang#36793 this commit attempts to head off any future problems by adding a custom `WidentUsizeHasher` which will widen any hashing of `isize` and `usize` to a `u64` as necessary. This obviates the need for a previous number of `as u64` annotations and will hopefully protect us against future problems here. Closes rust-lang#36793 (hopefully)
|
IIUC, this bug breaks 64-bit -> 32-bit i686 builds on the beta channel. We are getting close to the release of Rust 1.13 and it would be good to see a beta build with the fixes soon so that projects (like mine) can make sure that we're fully compatible with the Rust 1.13 release in time to report any other (unrelated) issues. |
|
@briansmith they've been a little slow to get out, but new beta builds are now available (as of a few hours ago) |
I confirmed that my builds are working with yesterday's beta build. Thanks! |
|
FYI: The current powerpc-unknown-linux-gnu build in the Beta channel (1.14) seems to be still affected by this: The symbol actually present in the library is |
|
@zeldin Does the nightly work? |
|
No, the nightly has the same problem: And the symbol in the library is |
|
PR #38357 refactored the symbol hashing code a bit. Maybe it accidentally broke something. We should check if this reappeared recently or was broken all along for these targets. |
|
Or maybe we fixed 32 bit vs 64 bit but not endianess (at least not all cases)? |
|
Current ppc32 nightly is working now, so I guess someone unbroke something again? 😄 |
In today's most recent nightly:
Compiling a simple program:
yields
Seems odd to have an undefined symbol in the standard library! Taking a look at what's actually inside:
Looks like the hashes are different!
Did we perhaps leak a usize into metadata/symbol calculation?
cc @eddyb
cc @michaelwoerister
The text was updated successfully, but these errors were encountered: