Assertion breaks in llvm when -g is used. #13681
Comments
|
A link to the bigger project would help. There's not much to go on here. |
|
I just got the project approved so you can reproduce the bug now. The code is at https://github.com/hackndev/zinc, uncomment -g line at |
|
A bit more context, it fails here: DIE *DwarfUnit::getOrCreateTypeDIE(const MDNode *TyNode) {
if (!TyNode)
return NULL;
DIType Ty(TyNode);
assert(Ty.isType());
assert(Ty == resolve(Ty.getRef()) &&
"type was not uniqued, possible ODR violation.");where |
|
I just hit this today. Here's a minimal set of files that will trigger the issue. I used delta and a bit of massaging to strip all the flavor out of them: @farcaller I found that both -g and -Z lto were required to repro this. If you need to debug your code, you can temporarily disable lto and hopefully your project will build. |
|
Thanks for providing a small test case, @sruggier, that's very helpful! |
|
So, this is a problem with unique type ids not being so unique when bitcode from different crates gets mixed together, as is the case with link-time-optimization. I'll work on a fix over the next days. |
|
And it's broken again: |
This reverts commit 6f135b0.
This reverts commit 6f135b0.
This seems to be a different issue. Feel free to open a new bug, preferable with a title specific to the assertion happening |
|
Sure, opened #14930 |
|
I get is this the same issue? |
|
@iopq It's been long enough that it's worth filing separately, I think. |
…r=Veykril fix: check tail expressions more precisely in `extract_function` Fixes rust-lang#13620 When extracting expressions with control flows into a function, we can avoid wrapping tail expressions in `Option` or `Result` when they are also tail expressions of the container we're extracting from (see rust-lang#7840, rust-lang#9773). This is controlled by `ContainerInfo::is_in_tail`, but we've been computing it by checking if the tail expression of the range to extract is contained in the container's syntactically last expression, which may be a block that contains both tail and non-tail expressions (e.g. in rust-lang#13620, the range to be extracted is not a tail expression but we set the flag to true). This PR tries to compute the flag as precise as possible by utilizing `for_each_tail_expr()` (and also moves the flag to `Function` struct as it's more of a property of the function to be extracted than of the container).
rust-lang#13698) Two changes to `redundant_guards`: - Lint float literals. We used to do that before but that was changed in rust-lang#11305 because at the time there was a future compat warning and it was planned to make pattern matching floats a hard error. In rust-lang#116284 it was decided to actually remove the lint and only make matching `NAN` specifically a hard error. The `NAN` part isn't relevant/important here because this PR only changes what literals are warned and `f64::NAN` isn't a literal, but I've added a test anyway to make sure we continue to not lint there. - Don't lint CStr literals because that can't be a pattern right now (fixes rust-lang#13681) changelog: none
On recent rust, compiling the code with
-gfails withHere's the backtrace:
Unfortunately, I cannot provide a small demo code to reproduce this (can reproduce only on the big project).
The text was updated successfully, but these errors were encountered: