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 089DA3888C4E for ; Fri, 18 Mar 2022 18:27:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 089DA3888C4E Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-85-hskMmbr1M3qwy8ONlhuz9w-1; Fri, 18 Mar 2022 14:27:32 -0400 X-MC-Unique: hskMmbr1M3qwy8ONlhuz9w-1 Received: by mail-qv1-f71.google.com with SMTP id o1-20020a0c9001000000b00440e415a3a2so4509561qvo.13 for ; Fri, 18 Mar 2022 11:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=U4EsivAWFsXOsna5MCp4cb9niiEA3f6Ns2s96NT8z6Q=; b=llijSlG2mKSZR1vjNoUVOh4gY6pzXtjv/hmoYVj3zgvrvurQbMoiWo96VZ2Hig8wPx c5VlZhflvOxpM+NlT75TWgygCXuzk61TJZvGZacAo6FFCsumU3KNMZUIeiOIadc0Ep8S EZ68RK8zI8h23e9h+JJtdl2vZHj43OQbJPSs07gpcJt3a2dytVgjIHL4QTAyyHfSGA4r c5Eh7WWOID2eiCcKPUke9Kkxx8wGp9oTqVAihU3+xWiqBlmuc6ryWmnsd9J1WrkvwTPT +Y7F0BA313K1kGDAv2GQMM9u6416rXk6CXGGF7xAusB3rFcZbDDReE/KWlFiSJ3jcEdH GnXw== X-Gm-Message-State: AOAM533/E80QbFnVjAxt+AH1R27b7VkYxp6bJBUvhPoAavKJOD6ixw/3 h8wEtuVVZ+2mgZnP/Hc+SrpEJyk1ie9rixxyegbfKMh1SUhQOf7wdIszFdmSvnxxo52qpFGPVbY 9tCHgmDH+WwZH4JF9Dg== X-Received: by 2002:ac8:7dd1:0:b0:2e1:c708:12fa with SMTP id c17-20020ac87dd1000000b002e1c70812famr8353312qte.532.1647628051717; Fri, 18 Mar 2022 11:27:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPs2rQjNgFwY507jdrzac+IzR1mMCkNyubqPTY4QYMakQFxuAZ5jgG+PhNOGrh1Y4T943w1w== X-Received: by 2002:ac8:7dd1:0:b0:2e1:c708:12fa with SMTP id c17-20020ac87dd1000000b002e1c70812famr8353294qte.532.1647628051361; Fri, 18 Mar 2022 11:27:31 -0700 (PDT) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id a129-20020a376687000000b0067d186d953bsm4055212qkc.121.2022.03.18.11.27.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 11:27:30 -0700 (PDT) Message-ID: Date: Fri, 18 Mar 2022 14:27:30 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) To: Jakub Jelinek Cc: Qing Zhao , gcc-patches Paul A Clarke via 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> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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:27:36 -0000 On 3/18/22 14:20, Jakub Jelinek wrote: > 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. One important point about the OP's testcase is that we're dealing with offset 0, which corresponds to both the PMF as a whole and its first element. Since we're looking for a RECORD_TYPE, choosing to interpret the desired object as the (RECORD_TYPE) PMF as a whole seems like the better choice; being more flexible probably does make sense at non-0 offsets. Jason