[PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

Jason Merrill jason@redhat.com
Fri Mar 18 17:35:53 GMT 2022

On 3/15/22 12:06, Jakub Jelinek wrote:
> On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
>>> The intent of r11-6729 is that it prints something that helps user to figure
>>> out what exactly is being accessed.
>>> When we find a unique non-static data member that is being accessed, even
>>> when we can't fold it nicely, IMNSHO it is better to print
>>>     ((sometype *)&var)->field
>>> or
>>>     (*(sometype *)&var).field
>>> instead of
>>>     *(fieldtype *)((char *)&var + 56)
>>> because the user doesn't know what is at offset 56, we shouldn't ask user
>>> to decipher structure layout etc.
>> The problem is that the reference is *not* to any non-static data member,
>> it's to the PMF as a whole.  But c_fold_indirect_ref_for_warn wrongly turns
>> it into a reference to the first non-static data member.
>> We asked c_fold_indirect_ref_warn to fold a MEM_REF with RECORD_TYPE, and it
>> gave us back a COMPONENT_REF with POINTER_TYPE.  That seems clearly wrong.
> That is not what I see on the testcase.
> I see the outer c_fold_indirect_ref_for_warn call with type ptrmemfunc
> which is a 64-bit RECORD_TYPE containing a single ptr member which has
> pointer to function type, and op which is the x VAR_DECL with sp type which
> is 128-bit RECORD_TYPE containing 64-bit __pfn member and 64-bit __delta
> member.


> As all the bits of the ptrmemfunc RECORD_TYPE fit within the __pfn member
> (they are equal size), it wants to print (cast)(something.__pfn).

I disagree that this is what we want; we asked to fold an expression 
with class type, it seems unlikely that we want to get back an 
expression with pointer type.


More information about the Gcc-patches mailing list