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 678753858D20 for ; Wed, 5 Apr 2023 13:25:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 678753858D20 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-173-41.tugraz.at (vra-173-41.tugraz.at [129.27.173.41]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Ps53f5727z1LM0N; Wed, 5 Apr 2023 15:25:34 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4Ps53f5727z1LM0N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1680701135; bh=id6H5ql3+icim+Qk7YLlXAMmjVw/vWlfQ4VdVEyeTSU=; h=Subject:From:To:Date:In-Reply-To:References:From; b=RZ0nXWD4YQMLvM5d0hqeADWNIzzN1wR1FvchRYmjddxlBH8zwUPIa/vT9mm0j3BOb 3k+RJKHAeUrYjDVOOiS8ZejlIbWRxc3QcG+rskaqqT0clNWNaLNfn6dDuHQrtdgD76 UUhQZmKBg79pctZY+tZhjBUW6IMdMO3h3EH+oMwg= Message-ID: <08213278b2703d14fc298ecdcdb0fa94dc9f3d0c.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: Wed, 05 Apr 2023 15:25:33 +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.1 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 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. The false positives are a regression relative to earlier version of GCC because the warnings are completely new (since GCC 11). I could bring this back later, but this means there is another version of GCC where  one might need to turn off these warnings. My concern is also that an otherwise very useful feature that brings some safety benefits gets underused. Martin