From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 822EA3858D33 for ; Thu, 20 Apr 2023 07:00:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 822EA3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at Received: from vra-169-237.tugraz.at (vra-169-237.tugraz.at [129.27.169.237]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Q27pZ6ksLz1LM0F; Thu, 20 Apr 2023 09:00:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4Q27pZ6ksLz1LM0F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1681974039; bh=a8emh0uEp/ww1RMB/TGdljY55cJbs6JkiP//YoLkYZk=; h=Subject:From:To:Date:In-Reply-To:References:From; b=gA9Bg2ZwuFACKW0QUH2bi3kwUKfzTBG3mxdbjjN9+eUWdDNLSyb1q9Pu9/4/jg337 vq+m1fOU3k1/yYFRraOemWY4neU02ZPP4/eHY5pZEK2O+z5qxoX4w/rsm5prJz6jBc j9XSif6qCnMigYJ73sVYSSj8yDsPxyM/zQ9tkq+Q= Message-ID: <76c86298211d737a4a44cf0cf28953ae9d218193.camel@tugraz.at> Subject: Re: [PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536] From: Martin Uecker To: Jeff Law , gcc-patches@gcc.gnu.org Date: Thu, 20 Apr 2023 09:00:38 +0200 In-Reply-To: <7e3070d8-c214-808e-3e52-a22aba64d786@gmail.com> References: <7e3070d8-c214-808e-3e52-a22aba64d786@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Dienstag, dem 04.04.2023 um 19:31 -0600 schrieb Jeff Law: > > On 4/3/23 13:34, Martin Uecker via Gcc-patches wrote: > > > > > > With the relatively new warnings (11..) affecting VLA bounds, > > I now get a lot of false positives with -Wall. In general, I find > > the new warnings very useful, but they seem a bit too > > aggressive and some minor tweaks are needed, otherwise they are > > too noisy. This patch suggests two changes: > > > > 1. For VLA bounds non-null is implied only when 'static' is > > used (similar to clang) and not already when a bound > 0 is > > specified: > > > > int foo(int n, char buf[static n]); > > > > int foo(10, 0); // warning with 'static' but not without. > > > > > > (It also seems problematic to require a size of 0 to indicate > > that the pointer may be null, because 0 is not allowed in > > ISO C as a size. It is also inconsistent to how arrays with > > static bound behave.) > > > > There seems to be agreement about this change in PR98541. > > > > > > 2. GCC always warns when the number of unspecified > > bounds is different between two declarations: > > > > int foo(int n, char buf[*]); > > int foo(int n, char buf[n]); > > > > or > > > > int foo(int n, char buf[n]); > > int foo(int n, char buf[*]); > > > > But the first version is useful if the size expression > > can not be specified in a header (e.g. because it uses > > a macro or variable not available there) and there is > > currently no easy way to avoid this. The warning for > > both cases was by design,  but I suggest to limit the > > warning to the second case. > > > > Note that the logic currently applied by GCC is too > > simplistic anyway, as GCC does not warn for > > > > int foo(int x, int y, double m[*][y]); > > int foo(int x, int y, double m[x][*]); > > > > because the number of specified / unspecified bounds > > is the same. So I suggest to go with the attached > > patch now and add more precise warnings later > > if there is more experience with these warning > > in gernal and if this then still seems desirable. > > > > > > Martin > > > > > >      Less warnings for parameters declared as arrays [PR98541, PR98536] > >       > > > > > > > >      To avoid false positivies, tune the warnings for parameters declared > >      as arrays with size expressions. Only warn about null arguments with > >      'static'. Also do not warn when more bounds are specified in the new > >      declaration than before. > >       > > > > > > > >              PR c/98541 > >              PR c/98536 > >       > > > > > > > >              c-family/ > >              * c-warn.cc (warn_parm_array_mismatch): Do not warn if more > >              bounds are specified. > >       > > > > > > > >              gcc/ > >              * gimple-ssa-warn-access.cc > >                (pass_waccess::maybe_check_access_sizes): For VLA bounds > >              in parameters, only warn about null pointers with 'static'. > >       > > > > > > > >              gcc/testsuite: > >              * gcc.dg/Wnonnull-4: Adapt test. > >              * gcc.dg/Wstringop-overflow-40.c: Adapt test. > >              * gcc.dg/Wvla-parameter-4.c: Adapt test. > >              * gcc.dg/attr-access-2.c: Adapt test. > Neither appears to be a regression. Seems like it should defer to gcc-14. Then ok for trunk now? Martin