Hi, Jason, On Feb 9, 2022, at 3:01 PM, Qing Zhao via Gcc-patches <gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>> wrote:
On Feb 9, 2022, at 12:23 PM, Jason Merrill <ja...@redhat.com<mailto:ja...@redhat.com>> wrote: On 2/9/22 10:51, Qing Zhao wrote: On Feb 8, 2022, at 4:20 PM, Jason Merrill <ja...@redhat.com<mailto:ja...@redhat.com>> wrote: On 2/8/22 15:11, Qing Zhao wrote: Hi, This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 It's possible that the TYPE_NAME of a record_type is NULL, therefore when printing the TYPE_NAME, we should check and handle this special case. Please see the comment of pr101515 for more details. The fix is very simple, just check and special handle cases when TYPE_NAME is NULL. Bootstrapped and regression tested on both x86 and aarch64, no issues. Okay for commit? Thanks. Qing ===================================== From f37ee8d21b80cb77d8108cb97a487c84c530545b Mon Sep 17 00:00:00 2001 From: Qing Zhao <qing.z...@oracle.com> Date: Tue, 8 Feb 2022 16:10:37 +0000 Subject: [PATCH] Fix PR 101515 ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128. It's possible that the TYPE_NAME of a record_type is NULL, therefore when printing the TYPE_NAME, we should check and handle this special case. gcc/cp/ChangeLog: * cxx-pretty-print.cc (pp_cxx_unqualified_id): Check and handle the case when TYPE_NAME is NULL. gcc/testsuite/ChangeLog: * g++.dg/pr101515.C: New test. --- gcc/cp/cxx-pretty-print.cc | 5 ++++- gcc/testsuite/g++.dg/pr101515.C | 25 +++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/g++.dg/pr101515.C diff --git a/gcc/cp/cxx-pretty-print.cc b/gcc/cp/cxx-pretty-print.cc index 4f9a090e520d..744ed0add5ba 100644 --- a/gcc/cp/cxx-pretty-print.cc +++ b/gcc/cp/cxx-pretty-print.cc @@ -171,7 +171,10 @@ pp_cxx_unqualified_id (cxx_pretty_printer *pp, tree t) case ENUMERAL_TYPE: case TYPENAME_TYPE: case UNBOUND_CLASS_TEMPLATE: - pp_cxx_unqualified_id (pp, TYPE_NAME (t)); + if (TYPE_NAME (t)) + pp_cxx_unqualified_id (pp, TYPE_NAME (t)); + else + pp_string (pp, "<unnamed type>"); Hmm, but it's not an unnamed class, it's a pointer to member function type, and it would be better to avoid dumping compiler internal representations like the __pfn field name. Yes, It’s not an unnamed class, but the ICE happened when try to print the compiler generated member function type “__ptrmemfunc_type”, whose TYPE_NAME is NULLed during building this type in c++ FE and the c++ FE does not handle the case when TYPE_NAME is NULL correctly. So, there are two levels of issues: 1. The first level issue is that the current C++ FE does not handle the case TYPE_NAME being NULL correctly, this is indeed a bug in the current code and should be fixed as in the current patch. Sure, we might as well make this code more robust. But we can do better than <unnamed type> if we check TYPE_PTRMEMFUNC_P. Okay, so what should we print to the user if it's “TYPE_PTRMEMFUNC_P”? Print nothing or some special string? 2. The second level issue is what you suggested in the above, shall we print the “compiler generated internal type” to the user? And I agree with you that it might not be a good idea to print such compiler internal names to the user. Are we do this right now in general? (i.e, check whether the current TYPE is a source level TYPE or a compiler internal TYPE, and then only print out the name of TYPE for the source level TYPE?) and is there a bit in the TYPE to distinguish whether a TYPE is user -level type or a compiler generated internal type? I think the real problem comes sooner, when c_fold_indirect_ref_for_warn turns a MEM_REF with RECORD_TYPE into a COMPONENT_REF with POINTER_TYPE. What’s the major issue for this transformation? (I will study this in more details). We told c_fold_indirect_ref that we want a RECORD_TYPE (the PMF as a whole) and it gave us back a POINTER_TYPE instead (the __pmf member). Folding shouldn't change the type of an expression like that. Yes, this is not correct transformation, will study in more detail and try to fix it. After a deeper study of commit r11-6729-gadb520606ce3e1e1 (which triggered the ICE and introduced the new routine “c_fold_indirect_ref_for_warn”), from my understanding, the above transformation from a RECORD_TYPE (the PMF as a whole) to POINTER_TYPE (the __pmf member) is what the function intended to do as following: 1823 static tree 1824 c_fold_indirect_ref_for_warn (location_t loc, tree type, tree op, 1825 offset_int &off) 1826 { … 1870 /* ((foo *)&struct_with_foo_field)[x] => COMPONENT_REF */ 1871 else if (TREE_CODE (optype) == RECORD_TYPE) 1872 { 1873 for (tree field = TYPE_FIELDS (optype); 1874 field; field = DECL_CHAIN (field)) 1875 if (TREE_CODE (field) == FIELD_DECL … 1886 if (upos <= off && off < upos + el_sz) 1887 { 1888 tree cop = build3_loc (loc, COMPONENT_REF, TREE_TYPE (field), 1889 op, field, NULL_TREE); 1890 off = off - upos; The above code was used to transform a MEM_REF to a RECORD_TYPE to a COMPONENT_REF to the corresponding FIELD. And then finally print out this COMPONENT_REF as a BASE + offsetof (field), in which the “field” is the compiler generated __pmf member field of the class, and its TYPE_NAME is NULL. Since the current code of “cp/cxx-pretty-print.cc<http://cxx-pretty-print.cc>” does NOT handle the case when TYPE_NAME==NULL, therefore the ICE. So, I still think that the major issue with this bug is cp/cxx-pretty-print.cc<http://cxx-pretty-print.cc> does not handle the case when TYPE_NAME==NULL. This clearly is a bug that need to be fixed. Let me know if you have more comments and suggestions. thanks. Qing Qing Jason
