dblaikie added a comment. In D100630#2749625 <https://reviews.llvm.org/D100630#2749625>, @shchenz wrote:
> In D100630#2749594 <https://reviews.llvm.org/D100630#2749594>, @dblaikie > wrote: > >> In D100630#2749550 <https://reviews.llvm.org/D100630#2749550>, @shchenz >> wrote: >> >>> In D100630#2748899 <https://reviews.llvm.org/D100630#2748899>, @dblaikie >>> wrote: >>> >>>> Does this cause duplicate DW_TAG_reference_types in the output, if the >>>> input IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types? >>> >>> Yes, it will cause such issue in theory. I can not cook a case that has a >>> DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a >>> DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there >>> such usage that we both be rvalue-reference and lvalue-reference to a basic >>> type? >> >> Ah, I was less thinking of a case of an rvalue reference and a normal >> reference in the same chain - I was thinking more about two unrelated >> reference types. >> >> Try some code like: >> >> void f1(int &&x, int &y) { >> } >> >> I'm guessing without this change - you get 'x's type pointing to the >> rvalue_reference_type, 'y's type pointing to the reference_type, and both of >> those pointing to the 'int' DW_TAG_basic_type. >> >> But with this change I'm worried you'll get two copies of the >> DW_TAG_reference_type - one that replaces the rvalue reference, and then the >> real one. Instead you should get one copy that both 'x' and 'y' refer to, I >> think. > > Hmm, yeah, indeed, a duplicated `DW_TAG_reference_type` is generated. > > 0x00000069: DW_TAG_reference_type > DW_AT_type (0x0000006e "int") > > 0x0000006e: DW_TAG_base_type > DW_AT_name ("int") > DW_AT_encoding (DW_ATE_signed) > DW_AT_byte_size (0x04) > > 0x00000075: DW_TAG_reference_type > DW_AT_type (0x0000006e "int") > > I think rather than fixing the duplicated `DW_TAG_reference_type` in the > backend, maybe it is better to fix this strict DWARF issue in the FE like the > fix in the previous patch https://reviews.llvm.org/D100630?id=338755 > > What do you think? @dblaikie I'd still hope this issue could be addressed in the backend, but yeah - it might be non-trivial. @aprantl @probinson etc - any thoughts on this? ================ Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:398-399 + + // Assertion for other cases. + assert(true && "Tag is generated not following strict DWARF!"); + } ---------------- side note: Not sure what this assertion is for/does? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D100630/new/ https://reviews.llvm.org/D100630 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
