similar to: [LLVMdev] `Ty && "Trying to add a type that doesn't exist?

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

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

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but the DWARF 4 specification says that DW_AT_calling_convention is not a valid attribute for any of those three DWARF tags. Downstream object consumers that check to verify

Hello all, I am currently implementing support for DWARFv5 DW_AT_alignment attr and I got a question about align field in debug info section of IR/Bitcode. Currently it is being dumped almost in any case, however according to code we use align from DI* objects only when dealing with class/structure bitfields: DwarfUnit::constructMemberDIE. Dumping align information everywhere only for 1 case

Hi David, Sorry, I forget to attach the valgrind dump to this. I was not sure if my implementation was ok, so I wanted to ask if I've done something wrong first. Process terminating with default action of signal 11 (SIGSEGV) Access not within mapped region at address 0xB at 0x54F4516: llvm::object::COFFObjectFile::moveSectionNext(llvm::object::DataRefImpl&) const

Hello Adrian, sorry for the delay with the response. Somehow I missed your message.. On 09/13/2016 12:43 AM, Adrian Prantl wrote: >> On Sep 10, 2016, at 12:50 PM, Victor Leschuk via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I am currently implementing support for DWARFv5 DW_AT_alignment attr and I got a question about align field in

Hi all, sorry to post to both lists, but I'm running into an issue where clang-generated debug info is deemed to be invalid by LLVM tools (throws an assertion error in both llc and mcjit), and I'm not sure what the proper resolution is. Here's a test case; I last tested it on revision r210953: $ cat test1.cpp #include "test.h" test::Test<int> foo1() { return

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,

Hi All, I have question about 'isUnsignedDIType' function on 'llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp' When we want to generate object file with dwarf debug format, clang can generates 'DW_ATE_lo_user' encoding for complex integer type as follow: "clang/lib/CodeGen/CGDebugInfo.cpp" llvm::DIType *CGDebugInfo::CreateType(const ComplexType *Ty) { ... if

>Downstream object consumers that check to verify that a DWARF attr is appropriate for a given DWARF tag will appropriately flag an error. Such a downstream consumer is behaving inappropriately. DWARF is a "permissive" standard, and the use of an attribute in a novel situation is explicitly permitted (see section 1.3 of DWARF v4). Consumers are expected to ignore tags and

I have a fairly recent LLD/LTO llvm crashing on DIE *ContextDIE = getOrCreateContextDIE(Context) being null for a (local) variable. (Context is a DICompileUnit in this case, but it's not present in MDNodeToDieMap so it returns null. callstack is: llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) Line 718 C++ llvm::DwarfUnit::addType(llvm::DIE & Entity, const

+Adrian & Manman, Looks like this is a case of non-DIRef references ending up in the IR, and thus the references not being deduplicated. This could lead to some of the IR bloat that you guys implemented the DIRef stuff to reduce/avoid. The specific issue is that the type is slightly different in the two TUs (since the namespace scope it's contained within is different in the two TUs -

On Mon, Oct 3, 2016 at 2:24 PM Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Sep 30, 2016, at 4:05 PM, Victor Leschuk <vleschuk at accesssoftek.com> > wrote: > > > > Hello Adrian, sorry for the delay with the response. Somehow I missed > your message.. > > > > On 09/13/2016 12:43 AM, Adrian Prantl wrote: >

Oh, I see. Sorry I misunderstood. I'll try to come up with some minimal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a

>> Without needing to change how namespaces are handled. >> >> Yes, using DIRefs for namespaces would cause the actual type nodes to >> be deduplicated when they aren't even with the patch above, and that >> would help reduce debug info metadata further if that's >> useful/necessary. > > Exactly. While the above patch will cover up the problem, we

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..., ...] > >

On Tue, Jun 24, 2014 at 2:38 PM, Adrian Prantl <aprantl at apple.com> wrote: > I will take this. > > !5 = metadata !{metadata !"./test.h", metadata !"/Volumes/Data/radar/17052973"} > !6 = metadata !{i32 786489, metadata !5, null, metadata !"test", i32 1} ; [ DW_TAG_namespace ] [test] [line 1] > !4 = metadata !{i32 786434, metadata !5, metadata !6,

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

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

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