From: Jason Merrill <jason@redhat.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: gcc-patches Paul A Clarke via <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)
Date: Wed, 9 Feb 2022 13:23:55 -0500 [thread overview]
Message-ID: <319ad931-a975-e29c-7b8a-51534d657e01@redhat.com> (raw)
In-Reply-To: <C6BABB5F-74F8-4143-9794-0CD5D84CBD2B@oracle.com>
On 2/9/22 10:51, Qing Zhao wrote:
>
>
>> On Feb 8, 2022, at 4:20 PM, Jason Merrill <jason@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.zhao@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.
> 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.
Jason
next prev parent reply other threads:[~2022-02-09 18:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 20:11 Qing Zhao
2022-02-08 22:20 ` Jason Merrill
2022-02-09 15:51 ` Qing Zhao
2022-02-09 18:23 ` Jason Merrill [this message]
2022-02-09 21:01 ` Qing Zhao
2022-02-10 2:49 ` Jason Merrill
2022-02-11 16:07 ` Qing Zhao
2022-02-11 17:27 ` Jason Merrill
2022-02-11 18:11 ` Qing Zhao
2022-02-11 19:39 ` Jason Merrill
2022-02-11 20:29 ` Qing Zhao
2022-02-11 21:54 ` Jason Merrill
2022-02-11 22:19 ` Qing Zhao
2022-03-15 12:32 ` Jakub Jelinek
2022-03-15 15:57 ` Jason Merrill
2022-03-15 16:06 ` Jakub Jelinek
2022-03-18 17:35 ` Jason Merrill
2022-03-18 18:20 ` Jakub Jelinek
2022-03-18 18:27 ` Jason Merrill
2022-03-18 18:47 ` Jakub Jelinek
2022-03-19 5:32 ` Jason Merrill
2022-03-16 10:29 ` [PATCH] c-family: Fix ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 [PR101515] Jakub Jelinek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=319ad931-a975-e29c-7b8a-51534d657e01@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=qing.zhao@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).