According to https://en.cppreference.com/w/cpp/language/function the cv-qualifier is allowed only on non-static member functions, which are exactly the ones that have an implicit this-pointer parameter. cv - const/volatile qualification, only allowed in non-static member function declarations Are cv-qualified free functions or static member functions a GCC extension? If so, then doing what GCC does seems like exactly the right thing to do. It falls within the “permissive” nature of DWARF to do that. I don’t know that the DWARF standard should say anything special about it, though. --paulr
From: Dwarf-Discuss <dwarf-discuss-boun...@lists.dwarfstd.org> On Behalf Of David Blaikie via Dwarf-Discuss Sent: Tuesday, October 5, 2021 3:12 PM To: DWARF Discuss <dwarf-discuss@lists.dwarfstd.org> Subject: [Dwarf-Discuss] Inconsistency of C++ member function qualifiers C++ member functions can be qualified in a number of ways - classic CV (const and volatile) qualifiers, and since C++11, lvalue (&) and rvalue (&&) reference qualifiers. Details here: https://en.cppreference.com/w/cpp/language/member_functions<https://urldefense.com/v3/__https:/en.cppreference.com/w/cpp/language/member_functions__;!!JmoZiZGBv3RvKRSx!tqhSDxClelx78nUz9oi9l27R5fYiWC6bR-gPJvMTM8FbJ-K2FSVDb2wi9pRr3rfbCg$> A note on 5.10, page 127 says: "C++ const-volatile qualifiers are encoded as part of the type of the “this”-pointer. C++11 reference and rvalue-reference qualifiers are encoded using the DW_AT_reference and DW_AT_rvalue_reference attributes, respectively. See also Section 5.7.8 on page 120." Though this appears to be inadequate, because C++ allows these qualifiers on any function type - even one without a first parameter necessary to carry the const/volatile qualifiers. eg: template<typename T> struct t1 { }; t1<void () const> v1; GCC implements this type by using DW_TAG_const_type around a DW_TAG_subroutine_type. I've implemented the same behavior in Clang recently. For actual member functions (eg: void (some_type::*)() const) both Clang and GCC put the const type on the artificial first parameter rather than by wrapping the type in DW_TAG_const_type. Does this seem acceptable, should we do something different to unify the representation between these two cases? Should we add some more non-normative text in 5.10/p127?
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org