similar to: lld/lto/win32 crash on DIE code

Hello Carlo, I tried your reproducer and faced different problem from one you described (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext This happens because LLVM

Op 16-3-2018 om 20:16 schreef Evgeny Leviant: > Hello Carlo, > > I tried your reproducer and faced different problem from one you described > (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens > when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: > >

This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction in @_island_debug_invoke and many other functions. The code expects either pointer to a filter function or null in first operand, while you're passing pointer to structure: catchpad within %80 [{i8*, i8*}* anon..., ...] ________________________________________ От: Carlo Kok <ck at

Op 20-3-2018 om 12:40 schreef Evgeny Leviant: > This one triggers an assertion in calculateSEHStateNumbers due to weird catchpad instruction > in @_island_debug_invoke and many other functions. The code expects either pointer to a filter > function or null in first operand, while you're passing pointer to structure: > > catchpad within %80 [{i8*, i8*}* anon..., ...] > >

Hi, I am learning to write LLVM modules. I am using IRBuilder to insert calls to an existing function. The call is to be inserted at a random location in every function in the code. The call does get inserted, however, the module crashes later (after doFinalization()). The crash happens only sometimes, not always. These are the kind of instructions that I see in the generated code. %callins =

It looks the problem lies in how your compiler generates debug info. LLVM doesn't expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { - if (!Context || isa<DIFile>(Context)) + if (!Context || isa<DIFile>(Context) || isa<DICompileUnit>(Context)) However, I suggest talking to

Pete Cooper and I have been looking at memory profiles of running llc on verify-uselistorder.lto.opt.bc (ld -save-temps dump just before CodeGen of building verify-uselistorder with -flto -g). I've attached leak-backend.patch, which we're using to make Intrustruments more accurate (instead of effectively leaking things onto BumpPtrAllocators, really leak them with malloc()). (I've

David, Dean, all, The bots got red today with assertion failures in llvm::DbgVariable::addMMIEntry: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/1816/steps/check-msan%20in%20gcc%20build/logs/stdio I did not find the offender yet. Any ideas? clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void

Thanks! On Mon, May 8, 2017 at 6:25 PM, Reid Kleckner <rnk at google.com> wrote: > I give it 99% odds it was r302483. Let's revert and debug it tomorrow. > > On Mon, May 8, 2017 at 6:20 PM, Kostya Serebryany via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> David, Dean, all, >> >> The bots got red today with assertion failures in >>

(Moving to LLVM-dev). I hope thats ok to just move the conversation over from commits. To summarise, selection DAG crashes if personality functions are not actually functions. This conversation is to try work out if that is a restriction we want to document in LangRef, or (as David B suggests), we should allow opaque values to be personality functions. I don’t actually know EH code at all, so

>From a thread with Adrian on llvm-commits I looked a little at cases where DwarfCompileUnit's getOrCreateContextDIE's "fallback to return the CU" didn't fire when a CU DIE was required (ie: when the "getDIE" call actually found the CU before the fallback happened) This seems unnecessary, and any case where we do this (where a metadata node has a non-null

Hi, I'm hitting an assertion "overlapping or duplicate fragments" in the DWARF codegen in addFragmentOffset(). This originates from a duplicated dbg.declare intrinsic, declaring the same fragment twice. The duplicated call was generated by the jump threading pass. I have a patch (see below) that removes simply such duplicates, but I'm not sure whether that is the right

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

Hello, I'm having this error and couldn't find a resolution from online, any help would be greatly appreciated: clang: /export/home/hzhang86/chapel/chapel-llvm36/chapel/third-party/llvm/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:839: void llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType, llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that doesn't

I think this is https://llvm.org/bugs/show_bug.cgi?id=16846 On Jun 4, 2015 12:04 PM, "Hui Zhang" <wayne.huizhang at gmail.com> wrote: > Is there any clue for this error ? > > Thanks > > On Tue, Jun 2, 2015 at 5:47 PM, Hui Zhang <wayne.huizhang at gmail.com> > wrote: > >> Hello, >> >> I'm having this error and couldn't find a

Hi Björn, I don't have any answers, just more confusion. Hopefully someone else can bring some light to this. I'm also interested in dbg.declares and what the rules are regarding them since it's not very clear to me at the moment. A similar fix as yours was made for duplicate non-fragment dbg.declares in r305244 and there is a bit of discussion about it in

Upgrade clang? I can't reproduce it with trunk. On 4 June 2015 at 14:48, Hui Zhang <wayne.huizhang at gmail.com> wrote: > Yes, I found this link, but what's the solution?? > > On Thu, Jun 4, 2015 at 1:09 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> I think this is https://llvm.org/bugs/show_bug.cgi?id=16846 >> >> On

Seems like something infinite-recursion like to me: $ clang --version clang version 6.0.0 (trunk 317833) Target: powerpc64le-unknown-linux-gnu $ clang -c test.ll warning: overriding the module target triple with powerpc64le-unknown-linux-gnu [-Woverride-module] ... #255 0x0000000012b07a78 llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*) ... So I'd say it reproduces. On Wed, Nov 15,

We're inconsistent about using DW_AT_MIPS_linkage_name versus DW_AT_linkage_name. Variables (see DwarfCompileUnit::getOrCreateGlobalVariableDIE()) get the standard attribute for DWARF >= 4, MIPS for older. Subprograms (see DwarfUnit::applySubprogramDefinitionAttributes()) always get DW_AT_MIPS_linkage_name (no version check). Before I go drudging through however many tests will die if I

Hi, This is my first post to this list, so I apologize in advance if I mess up on any list etiquette. Jumping right in, I’m making use of the DebugInfo/DWARF APIs to get debugging information out of binaries (what else!). One of the bits of data I need is the location information stored in the location list section as well as inline in DW_AT_location attributes and similar. So far I’ve succeeded