From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 64B593858C2C for ; Fri, 18 Mar 2022 18:20:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 64B593858C2C Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-567-NZQjAhEsOmKtBBHojYWNmg-1; Fri, 18 Mar 2022 14:20:40 -0400 X-MC-Unique: NZQjAhEsOmKtBBHojYWNmg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1D6AA3803508; Fri, 18 Mar 2022 18:20:40 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE2C5492CAE; Fri, 18 Mar 2022 18:20:39 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 22IIKaqT1832979 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 18 Mar 2022 19:20:37 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 22IIKa671832978; Fri, 18 Mar 2022 19:20:36 +0100 Date: Fri, 18 Mar 2022 19:20:36 +0100 From: Jakub Jelinek To: Jason Merrill Cc: Qing Zhao , gcc-patches Paul A Clarke via Subject: Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) Message-ID: Reply-To: Jakub Jelinek References: <87823a36-93f3-5541-dc76-5a8c32e51c03@redhat.com> <319ad931-a975-e29c-7b8a-51534d657e01@redhat.com> <9B1729F5-964A-4A12-93B3-148BFE4D96F5@oracle.com> <01B0A297-CC89-4666-9684-BE04BE17E66E@oracle.com> <8fb4f228-16c7-9f3b-412c-bcea1a2020e7@redhat.com> <907b5cc5-8f80-11f7-8a2b-c2daffd6d6b1@redhat.com> MIME-Version: 1.0 In-Reply-To: <907b5cc5-8f80-11f7-8a2b-c2daffd6d6b1@redhat.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2022 18:20:46 -0000 On Fri, Mar 18, 2022 at 01:35:53PM -0400, Jason Merrill wrote: > 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. > > Exactly: TYPE is RECORD_TYPE, TREE_TYPE (field) is POINTER_TYPE. > > > 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. That doesn't matter. What c_fold_indirect_ref_warn returns is something that can help the user understand what is actually being accessed. Consider slightly modified testcase (which doesn't use the PMFs so that we don't ICE on those too): // PR c++/101515 // { dg-do compile } // { dg-options "-O1 -Wuninitialized" } struct S { int j; }; struct T : public S { virtual void h () {} }; struct U { char buf[32]; void (*ptr) (); }; struct sp { char a[14]; char b[50]; void (*pfn) (); long delta; }; int main () { T t; sp x; U *xp = (U *) &x.b[18]; if (xp->ptr != ((void (*) ()) (sizeof (void *)))) return 1; } Trunk emits: pr101515-2.C: In function ‘int main()’: pr101515-2.C:16:11: warning: ‘*(U*)((char*)&x + offsetof(sp, sp::b[18])).U::ptr’ is used uninitialized [-Wuninitialized] 16 | if (xp->ptr != ((void (*) ()) (sizeof (void *)))) | ~~~~^~~ pr101515-2.C:14:6: note: ‘x’ declared here 14 | sp x; | ^ here, which is indeed quite long expression, but valid C++ and helps the user to narrow down what exactly is being accessed. If I comment out the c_fold_indirect_ref_warn RECORD_TYPE handling so that it punts on it, it prints: pr101515-2.C: In function ‘int main()’: pr101515-2.C:16:11: warning: ‘*(U*)((char*)&x + 32).U::ptr’ is used uninitialized [-Wuninitialized] 16 | if (xp->ptr != ((void (*) ()) (sizeof (void *)))) | ~~~~^~~ pr101515-2.C:14:6: note: ‘x’ declared here 14 | sp x; | ^ That is also correct C++ expression, but user probably has no idea what is present at offset 32 into the variable. Of course if there is a type match and not any kind of type punning, it will try to print much shorter and more readable expressions. Jakub