search for: scopenod

Thanks for the quick response. I wrote some code to search “llvm.dbg.cu” for the function (right before the failed assertion): if (TheCU == nullptr) { errs() << "compile unit: " << TheCU << "\n scopeNode(" << FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; auto fn = MF->getFunction(); errs() << " fn => " << fn->getName() << "\n"; MDNode *node = nullptr;...

...e: >> Thanks for the quick response. >> >> I wrote some code to search “llvm.dbg.cu” for the function (right before the >> failed assertion): >> >> if (TheCU == nullptr) { >> errs() << "compile unit: " << TheCU << "\n scopeNode(" << >> FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; >> auto fn = MF->getFunction(); >> errs() << " fn => " << fn->getName() << "\n"; >&...

...t cs.washington.edu> wrote: > Thanks for the quick response. > > I wrote some code to search “llvm.dbg.cu” for the function (right before the > failed assertion): > > if (TheCU == nullptr) { > errs() << "compile unit: " << TheCU << "\n scopeNode(" << > FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; > auto fn = MF->getFunction(); > errs() << " fn => " << fn->getName() << "\n"; > > > &g...

...he quick response. >>> >>> I wrote some code to search “llvm.dbg.cu” for the function (right before the >>> failed assertion): >>> >>> if (TheCU == nullptr) { >>> errs() << "compile unit: " << TheCU << "\n scopeNode(" << >>> FnScope->getScopeNode() << ") => " << *FnScope->getScopeNode() << "\n"; >>> auto fn = MF->getFunction(); >>> errs() << " fn => " << fn->getName() << "\n&qu...

...0x00000001033015c3 main + 7283 >> 23 libdyld.dylib 0x00007fff8e68d5fd start + 1 > > (note the line number of the assertion is probably different because I’ve added some prints to help me debug this) > > When I print the MDNode returned by “FnScope->getScopeNode()”, I get lots of <badref>’s: The badrefs are a red herring, so far as I know - they're printed that way even when they're valid references, in my experience. That being said, given your assertion it does look like /something/ is up. It appears as if the function being emitted is...

...925 > 22 clang-3.4 0x00000001033015c3 main + 7283 > 23 libdyld.dylib 0x00007fff8e68d5fd start + 1 (note the line number of the assertion is probably different because I’ve added some prints to help me debug this) When I print the MDNode returned by “FnScope->getScopeNode()”, I get lots of <badref>’s: > !{i32 786478, metadata <badref>, metadata <badref>, metadata !"grappa_wide_get_pointer", metadata !"grappa_wide_get_pointer", metadata !"", i32 53, metadata <badref>, i1 false, i1 true, i32 0, i32 0, null, i3...