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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 8D98B3857C61 for ; Thu, 25 Feb 2021 23:47:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8D98B3857C61 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-539-DQIPDslMO_SSrFIaAwdbjA-1; Thu, 25 Feb 2021 18:47:57 -0500 X-MC-Unique: DQIPDslMO_SSrFIaAwdbjA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4671C185A0C9; Thu, 25 Feb 2021 23:47:56 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-98.phx2.redhat.com [10.3.112.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id EF4555D9D2; Thu, 25 Feb 2021 23:47:55 +0000 (UTC) Subject: Re: PING [PATCH] avoid -Warray-bounds checks for vtable assignments (PR 98266) To: Jason Merrill , Martin Sebor , gcc-patches References: <7fa3c1e0-8a09-3436-8669-6d1a577ca247@gmail.com> <55235bab-1a5a-4e3b-3a57-55d9a84ae00c@redhat.com> <042e2b8f-3031-519d-4a2f-1cb33e2004a7@gmail.com> <354bf06f-ad62-7966-a5d5-e4931ed1d5ed@redhat.com> <355d1e90-bba2-ad97-3544-c8fda473cfa0@gmail.com> <571fbfd1-d0f1-c1ca-1eef-4e804d7f8088@redhat.com> <8067ec57-5bb5-87a3-6a72-7ab43004248c@gmail.com> <3ced50a4-06b9-f83b-da73-9c4842944714@redhat.com> From: Jeff Law Message-ID: <7f95f61e-00b9-5fa3-a07a-143dc5fe6045@redhat.com> Date: Thu, 25 Feb 2021 16:47:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <3ced50a4-06b9-f83b-da73-9c4842944714@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-6.0 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_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 25 Feb 2021 23:48:00 -0000 On 2/23/21 2:52 PM, Jason Merrill wrote: > > I don't see how the issue here depends on the artificiality of the vptr; That's what I was trying to get at -- is DECL_ARTIFICIAL really a good way to detect these kinds of cases.  It sounds like it likely isn't, but it may also be the best we can do.  I'm not sure yet. > I'd expect to see the same problem with a data member.  The problem is > that a D base subobject is smaller than a complete D object, and in > this case the base subobject is allocated such that if it were a full > D object, it would overlap the end of E.  And we're checking the > MEM_REF as though accessing a full D object, so we get a warning. > > The general issue about the confusion between complete and as-base > types is PR 22488; I have various thoughts about a proper fix, but > there have always been higher-priority things to work on. > > One possible approach to this PR is that we don't need to check an > intermediate _REF; in > > MEM[(struct D *)&D.2651 + 24B]._vptr.D > > we aren't loading a whole D, we're only looking at the _vptr, which is > within the bounds of E. That raises a really interesting question.  What's the right bounds to use with these kinds of constructs.  Should we be looking at D's type (struct E) or struct D?  I'm not sure there's a one-size-fits-all answer here and I don't think we have any other context go help guide us. Jeff