-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Cannot represent a difference across sections #109730
Comments
here probably more info on how to reproduce could help. If I read the CI log correctly, the test alone compiles but it fails when enabling the @rustbot label E-needs-mcve |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer. |
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1: |
@nikic I'll try a build with that patch. One thing to note though, regarding:
The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.) |
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release. |
…michaelwoerister debuginfo: split method declaration and definition When we're adding a method to a type DIE, we only want a DW_AT_declaration there, because LLVM LTO can't unify type definitions when a child DIE is a full subprogram definition. Now the subprogram definition gets added at the CU level with a specification link back to the abstract declaration. Both GCC and Clang write debuginfo this way for C++ class methods. Fixes rust-lang#109730. Fixes rust-lang#109934.
Since nightly release
2023-03-25
, we've had build failures foragb
(https://github.com/agbrs/agb) with messageCannot represent a difference across sections
when lto is enabled.If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue.
Code
You can reproduce the issue if you build the
test_save_eeprom_512b
test in release mode:I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered.
Version it worked on
It most recently worked on: Rust nightly 2023-03-23
Version with regression
rustc --version --verbose
:Compiler output
The error message isn't particularly helpful here, but here is the full output from our github action:
The text was updated successfully, but these errors were encountered: