Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I attach a tarball with a small reproducer (few dependencies from , lock file, empty ). Now run this using rustc 1.56.0: I expect the sha256sum to be the same for the libpalette so file but it's often different. This breaks any binary caches, similarly to what did but that ticket turned out to be a problem with the crate. This time it seems problem with itself (or rather LLVM: stay tuned): 1.55.0 produces same binary/crate hash on every build. Note that in there's: Without this, the issue does not present itself. This perhaps makes it look similar to or but I think it's different. As far as I saw, it didn't produce a difference in ordering of symbols in the resulting though I may be mistaken. Please feel free to close as duplicate if you deem it to be the same issue. I have ran with and after careful sifting through few GiB of output, I found the differences seem to start in . I have bisected itself and ran it on our original code which exhibited the problem. I started the bisect at common merge point with 1.55.0 though the problem turned out well into the 1.56.0 release: cc who did the update : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
One thing I found: if I run it with I can't reproduce it anymore. claim
Well, I was wrong. Still reproducible even with . Produced files are identical though.
Consistent with my findings with as well.
Update: this IS a LLVM bug, I'm able to reproduce it with just ll input file using mainline LLVM. Filed to LLVM.
I have a fix: Do we want to apply it to llvm-rust or are we going to wait for LLVM review?
Good job, thank you!
I wonder if rust needs too.
Answering my own question: it does.
Could you also do a PR for
Sure, will do.
Created
Actually I was too slow, there is already
FWIW, while taking the 1.56.0 source and applying the 2 LLVM reproducibility patches fixes the issues we have with Firefox, the latest nightly doesn't: there's a remaining reproducibility issue on i686 linux. I'll test a patched beta next.
The next beta release should be fixed, per . (Should go out near 00:00 UTC -- I guess it will be .)
the beta branch + the patches seems to fix it, but I've found something new: depending how llvm is built, the result can vary. Specifically, llvm built with a sysroot exhibits reproducibility issues that are not present when not building with a sysroot. I'll wait for the official build for 1.57.0-beta.4 for a definite answer whether the issue is fixed. One thing is sure, though, there's an additional regression in nightly.
So, as far as Firefox is concerned, everything is fixed in the latest betas. I did find a source of non-determinism that is not fixed, but a) it seems to also affects clang (as in, I also have found one in clang, and I think it's the same root cause) b) it goes away with PGO, so it doesn't actually affect Firefox.
is there a ticket about this one somewhere? It's great that it doesn't impact Firefox but it may be impacting other rust software
I haven't filed it because the smallest reproducer I have at the moment is "build firefox with these flags and observe how sometimes some functions have an extra mov", and from experience, those don't lead to any action.
I see, thanks. It sounds like binary-reproducability thing and ABI should(?) be the same at least. And this is a regression in new LLVM version (rustc 1.56 and beyond)?
I don't know if this affects rustc, but I narrowed down yet another source of non-determinism in debuginfo, and upstream came up with a patch:
We tried using 1.57.0 and it seems broken still. I'll try to get a repro tomorrow. Should I open a new ticket or will someone reopen this one?
Actually, seems it comes from a derive crate in our dependency tree, similar to what we saw in ; So maybe it's fine. EDIT:

Discussion:
<del> Subproject commit a7348ae0df3c71581dbe3d355fc0fb6ce6332dd0 </del> <ins> Subproject commit e048e97f5280e8a232a43ae134d395aeab67c2e8 </ins>