LLVM "conflicting locations for variable" assertions #138198
Assignees
Labels
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
E-needs-mcve
Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
jieyouxu
added
A-LLVM
|
Taking from the gentoo bug link for |
|
Potential reproducer according to the gentoo bug report is mls-platform-api v0.1.0 https://github.com/beurdouche/mls-platform-api?rev=19c3f18b747d13354370ba84440bb0b963932634#19c3f18b |
saethlin
added
I-crash
|
Are there STR that don't involve installing Gentoo? I built 79b43df with LLVM assertions enabled, then used the stage 2 compiler to build mozilla/gecko-dev@e31c7b6 with |
|
cc @yuri-sevatz |
|
Following steps from here: I manually re-ran the failing It generated this: ... these files are attached in upload.zip below: Here are the package versions which I had combined to get this, though others are saying it's the same result with
On this particular Gentoo installation, every package (including rust itself) would have been built with the below globals set in Since I've reproduced this on several other CPUs with a range of older as well as newer instruction sets, I don't think the above globals Hope that helps... I'll try and see if it's easy to hit this with Gentoo's livecd. Their "GUI" livecd might be a little closer to being able to test this with a lot less steps, provided you have the RAM for it. |
|
awslabs/mls-rs#231 looks potentially relevant |
|
Yeah reverting that and then doing |
jieyouxu
added
E-needs-mcve
|
I have confirmed that applying the same workaround to the 'mls-platform-api' folder in firefox's source code avoids the crash in rustc when compiling Gentoo's version of |
|
Unfortunately the assertion goes away with |
|
Disabling LTO also makes this go away. @rustbot label A-LTO |
|
Alright, after further investigation I think the LTO is just required to get SROA aggressive enough to trigger the assertion but isn't actually the root cause. @rustbot label -A-LTO The hacky commit that obscures this problem replaces the destructuring assignment (a, b) = (b, c);with a a = mem::replace(&mut b, c);That destructuring assignment is critical to tripping the assertion. Rustc desugars that assignment to { let (lhs, lhs) = (b, c); a = lhs; b = lhs; };Note the repeated and codegen proceeds the way one would expect. But that double %9 = alloca [24 x i8], align 8
%10 = alloca [24 x i8], align 8
...
#dbg_declare(ptr %10, !118437, !DIExpression(), !118494)
#dbg_declare(ptr %9, !118437, !DIExpression(), !118495)
...
!118437 = !DILocalVariable(name: "lhs", scope: !118438, file: !4703, line: 138, type: !1291, align: 64)
!118438 = distinct !DILexicalBlock(scope: !118432, file: !4703, line: 138, column: 13)
...
!118494 = !DILocation(line: 138, column: 34, scope: !118438, inlinedAt: !118439) ; i.e. the rhs of the destructuring
!118495 = !DILocation(line: 138, column: 14, scope: !118438, inlinedAt: !118439) ; i.e. the lhs of the destructuringrustc assigns both stack slots to the same DILocalVariable. Then, when the type is a struct (Vec in the repo in question) and SROA is aggressive enough to shred one of them into its constituents, the assertion is triggered. That's a lot to unpack, but my first question is why are we generating debuginfo for compiler-introduced-vars at all? |
khuey
added a commit
to khuey/rust
that referenced
this issue
Mar 22, 2025
…ugaring assignments.
An assignment such as
(a, b) = (b, c);
desugars to the HIR
{ let (lhs, lhs) = (b, c); a = lhs; b = lhs; };
The repeated `lhs` leads to multiple Locals assigned to the same DILocalVariable. Rather than
attempting to fix that, get rid of the debug info for these bindings that don't even exist
in the program to begin with.
Fixes rust-lang#138198
|
@rustbot claim |
TaKO8Ki
added a commit
to TaKO8Ki/rust
that referenced
this issue
Mar 24, 2025
Don't produce debug information for compiler-introduced-vars when desugaring assignments.
An assignment such as
(a, b) = (b, c);
desugars to the HIR
{ let (lhs, lhs) = (b, c); a = lhs; b = lhs; };
The repeated `lhs` leads to multiple Locals assigned to the same DILocalVariable. Rather than attempting to fix that, get rid of the debug info for these bindings that don't even exist in the program to begin with.
Fixes rust-lang#138198
r? `@jieyouxu`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally posted by @yuri-sevatz in #131944
The text was updated successfully, but these errors were encountered: