SouraVX added a comment. In D68117#1707680 <https://reviews.llvm.org/D68117#1707680>, @dblaikie wrote:
> In D68117#1707578 <https://reviews.llvm.org/D68117#1707578>, @SouraVX wrote: > > > In D68117#1702595 <https://reviews.llvm.org/D68117#1702595>, @probinson > > wrote: > > > > > We really do want to pack the four mutually exclusive cases into two > > > bits. I have tried to give more explicit comments inline to explain how > > > you would do this. It really should work fine, recognizing that the "not > > > defaulted" case is not explicitly represented in the textual IR because > > > it uses a zero value in the defaulted/deleted subfield of SPFlags. > > > > > > Thanks Paul, for suggesting this. Your approach works fine. But as I was > > working on some lvm-dwarfdump test cases. We seems to miss one corner case > > -- > > Consider this test case; > > class foo{ > > > > foo() = default; > > ~foo() = default; > > void not_special() {} > > > > }; > > void not_a_member_of_foo(){} > > > > Now I'm getting DW_AT_defaulted getting emitted with value DW_DEFAULTED_no, > > for functions "not_special" and "not_a_member_of_foo". This behavior is > > undesirable since, DW_AT_defaulted attributes is only valid for C++ special > > member functions{Constructors/Destructors, ...}. > > > > Please correct me if I'm wrong -- Now This attributes to- implicitly > > defined "0" NotDefaulted bit. which is getting checked{that's fine as long > > as we have a dedicated bits for distinguishing} and true for every > > subprogram or function in a CU. > > void DwarfUnit::applySubprogramAttributes( ... > > ... > > else if (SP->isNotDefaulted()) > > > > addUInt(SPDie, dwarf::DW_AT_defaulted, dwarf::DW_FORM_data1, > > dwarf::DW_DEFAULTED_no); > > > > ... > > > Perhaps we should only emit DEFAULTED_yes, and assume anything that's not > DEFAULTED_yes, is... not defaulted? > > Also: What features is anyone planning to build with this information? I'm > sort of inclined not to implement features without some use-case in > mind/planned. Hi David, thanks for your suggestion. But, if we do that way, we may not be able to capture it's location and, whether that function was defaulted in or out of class. Regarding the intent behind doing this, we have an initial internal requirement for 100% compliance towards DWARF-5 from producer{Clang} side. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68117/new/ https://reviews.llvm.org/D68117 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
