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 E7AAA385800C for ; Fri, 19 Feb 2021 04:28:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E7AAA385800C 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-597-BlXpk4LaO-yFYbXZ32E-PQ-1; Thu, 18 Feb 2021 23:28:17 -0500 X-MC-Unique: BlXpk4LaO-yFYbXZ32E-PQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DAFD91008303; Fri, 19 Feb 2021 04:28:16 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-53.phx2.redhat.com [10.3.112.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id AEEB857; Fri, 19 Feb 2021 04:28:16 +0000 (UTC) Subject: Re: [PATCH] improve warning suppression for inlined functions (PR 98465, 98512) To: Martin Sebor , gcc-patches References: <2e49b6c6-a403-a207-c41e-58f78df96b84@gmail.com> From: Jeff Law Message-ID: <775e9e45-5b9f-7b7d-5a62-615a11eb89bb@redhat.com> Date: Thu, 18 Feb 2021 21:28:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <2e49b6c6-a403-a207-c41e-58f78df96b84@gmail.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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=-5.8 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: Fri, 19 Feb 2021 04:28:21 -0000 On 1/19/21 11:58 AM, Martin Sebor via Gcc-patches wrote: > std::string tends to trigger a class of false positive out of bounds > access warnings for code GCC cannot prove is unreachable because of > missing aliasing constrains, and that ends up expanded inline into > user code.  Simply inserting the contents of a constant char array > does that.  In GCC 10 these false positives are suppressed due to > -Wno-system-headers, but in GCC 11, to help detect calls rendered > invalid by user code passing in either incorrect or insufficiently > constrained arguments, -Wno-system-header no longer has this effect > on invalid access warnings. > > To solve the problem without at least partially reverting the change > and going back to the GCC 10 way of things for the affected subset > of calls (just memcpy and memmove), the attached patch enhances > the #pragma GCC diagnostic machinery to consider not just a single > location for inlined code but all locations at which an expression > and its callers are inlined all the way up the stack.  This gives > each author of a function involved in inlining the ability to > control a warning issued for the code, not just the user into whose > code all the calls end up inlined.  To resolve PR 98465, it lets us > suppress the false positives selectively in std::string rather > than across the board in GCC. > > The solution is to provide a new pair of overloads for warning > functions that, instead of taking a single location argument, take > a tree node from which the location(s) are determined.  The tree > argument is indirect because the diagnostic machinery doesn't (and > cannot without more intrusive changes) at the moment depend on > the various tree definitions.  A nice feature of these overloads > is that they do away with the need for the %K directive (and in > the future also %G, with another enhancement to accept a gimple* > argument). > > This patch depends on the fix for PR 98664 (already approved but > not yet checked in).  I've tested it on x86_64-linux. > > To avoid fallout I tried to keep the changes to a minimum, and > so the design isn't as robust as I'd like it ultimately to be. > I plan to enhance it in stage 1. I'd lean towards deferring to gcc12 stage1 given the libstdc++ hack is in place.  That does mean that glibc will need to work around the instance they've stumbled over in ppc's rawmemchr. If there are other BZs where this would help our ability to "cleanly" suppress diagnosics with our pragmas, then we probably should link them together with 98512/98465 and defer them all to gcc-12. Jeff