From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 9A81F385840A for ; Mon, 24 Oct 2022 07:30:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9A81F385840A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 8F35122018; Mon, 24 Oct 2022 07:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666596657; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=64ttYTGdCSOUtuVxNkjx3e0hNMN0gP5/9yUQITDRIsA=; b=c4zk0ndVw2Q0zA9HnDqHH68/yo7L+MBRtXpyzCvDy6MFgMxUJTDf55bYhj52fEP47jcWqH WvN4NpyyVyKAxLhSRm2d5be/eg+hK4d48+JT8QBdZVCjtQTWCz/rjbFbGF872GuDO6SNxT xZ3Jwo51IixSJAO9llTP335gVJKvZO4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666596657; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=64ttYTGdCSOUtuVxNkjx3e0hNMN0gP5/9yUQITDRIsA=; b=QvzewGaV48nxBviAV87I8ajcTRB9twVGbXXqeXHgsJMAO4xfBDaM2cUCp/iYhOlwBZSYWW oyl1rMnfZBjAZhCg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 796F32C141; Mon, 24 Oct 2022 07:30:57 +0000 (UTC) Date: Mon, 24 Oct 2022 07:30:57 +0000 (UTC) From: Richard Biener To: Martin Sebor cc: Qing Zhao , Jakub Jelinek , gcc Patches Subject: Re: [RFC] how to handle the combination of -fstrict-flex-arrays + -Warray-bounds In-Reply-To: <56fa59d1-75d3-6698-51fb-3806b9559397@gmail.com> Message-ID: References: <695014B4-2A9E-49D6-BD40-4B24644FA1D6@oracle.com> <56fa59d1-75d3-6698-51fb-3806b9559397@gmail.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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: On Sat, 22 Oct 2022, Martin Sebor wrote: > On 10/21/22 09:29, Qing Zhao wrote: > > Hi, > > > > (FAM below refers to Flexible Array Members): > > > > I need inputs on how to handle the combination of -fstrict-flex-arrays + > > -Warray-bounds. > > > > Our initial goal is to update -Warray-bounds with multiple levels of > > -fstrict-flex-arrays=N > > to issue warnings according to the different levels of ?N?. > > However, after detailed study, I found that this goal was very hard to be > > achieved. > > > > 1. -fstrict-flex-arrays and its levels > > > > The new option -fstrict-flex-arrays has 4 levels: > > > > level trailing arrays > > treated as FAM > > > > 0 [],[0],[1],[n] the default without option > > 1 [],[0],[1] > > 2 [],[0] > > 3 [] the default when option specified > > without value > > > > 2. -Warray-bounds and its levels > > > > The option -Warray-bounds currently has 2 levels: > > > > level trailing arrays > > treated as FAM > > > > 1 [],[0],[1] the default when option specified > > without value > > 2 [] > > > > i.e, > > When -Warray-bounds=1, it treats [],[0],[1] as FAM, the same level as > > -fstrict-flex-arrays=1; > > When -Warray-bounds=2, it only treat [] as FAM, the same level as > > -fstrict-flex-arrays=3; > > > > 3. How to handle the combination of -fstrict-flex-arrays and > > -Warray-bounds? > > > > Question 1: when -fstrict-flex-arrays does not present, the default is > > -strict-flex-arrays=0, > > which treats [],[0],[1],[n] as FAM, so should we update > > the default behavior > > of -Warray-bounds to treat any trailing array [n] as > > FAMs? > > > > My immediate answer to Q1 is NO, we shouldn?t, that will be a big regression > > on -Warray-bounds, right? > > Yes, it would disable -Warray-bounds in the cases where it warns > for past-the-end accesses to trailing arrays with two or more > elements. Diagnosing those has historically (i.e., before recent > changes) been a design goal. > > > > > Question 2: when -fstrict-flex-arrays=N1 and -Warray-bounds=N2 present at > > the same time, > > Which one has higher priority? N1 or N2? > > > > -fstrict-flex-arrays=N1 controls how the compiler code generation treats the > > trailing arrays as FAMs, it seems > > reasonable to give higher priority to N1, > > I tend to agree. In other words, set N2' = min(N1, N2). Yes. Or do nothing and treat them independently. Can you check whether it's possible to distinguish -Warray-bounds from -Warray-bounds=N? I'd say that explicit -Warray-bounds=N should exactly get the documented set of diagnostis, independent of -fstrict-flex-arrays=N. > > However, then should we completely disable the level of -Warray-bounds > > N2 under such situation? > > > > I really don?t know what?s the best way to handle the conflict between N1 > > and N2. > > > > Can we completely cancel the 2 levels of -Warray-bounds, and always honor > > the level of -fstrict-flex-arrays? > > > > Any comments or suggestion will be helpful. > > The recent -fstrict-flex-array changes aside, IIRC, there's only > a subtle distinction between the two -Warray-bounds levels (since > level 1 started warning on a number of instances that only level > 2 used to diagnose a few releases ago). I think that subset of > level 2 could be merged into level 1 without increasing the rate > of false positives. Then level 2 could be assigned a new set of > potential problems to detect (such as past-the-end accesses to > trailing one-element arrays). > > Martin > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)