From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 648E73858D28 for ; Thu, 21 Mar 2024 07:11:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 648E73858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 648E73858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711005121; cv=none; b=gPIEkQ6IZIlcnp+Oo4wloSZKApuXEFN5pw4UQCnQJMeijrI94JBb2ja58LEx9A0Pgi9BaVZrAqCID2f4gH2zCA/Ye1daQZJDUoCXmhhnDViFsuBdM1fHdatVILLo0mYcruor4NbXeJ0Y64JPNfW5RgcciYtltSptNNrOnegiYZs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711005121; c=relaxed/simple; bh=8MB3IHHX4ESMeVmrvxAe9+kds+420WzsDmyJq90Br5k=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=LJik8QsB5bf7e8ukkrQW9ion9fNe2GcpRftjhs7TILn8gtQHzJGDyBykQWi7U/DmitpLC93WnmbFonqaefJeXxWK7lSLyxwi0+Lpc5LM6lenhi0ZAFB8jecBe+rl/RNmsYKLab5picprfnCxMRcvayHoAYtg6LiHwjx2pczUEpY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 42L70YPh024797 for ; Thu, 21 Mar 2024 07:11:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=pp1; bh=chm8ub33U1rT2+fpelZslWlFEojYmYM6ROzOjDzf8Jg=; b=BMXwN/OHMLf6ISmhGYXDhlcKtalfS9+MnvjhVgWz34FlspqHxAIiORceeCoujdGrY6lP VbbN8qDMBkX4su5/og8m03Mgp3gI+gp++c8hYUWCSOFfFZkeSKzfZAidzP3dJTv+aeIh Q+M1GXuPvsIEtVTrxFUbAvU4tL4jmU/jXFJQkJ40o5Gm6u7Yi1D/xKT6Nvl2VWqy0UVF 5RE+GE5ITsFLwk5KLyk9Sbc19FbkChjJNuEUcT4hjlR9Q9bavk4zz3IwYkMyAlvGUcIV BOIhrxlK3OxmXsW6FFebtnLq+DsVUZrCJHdB5T+8zXO8o73be0u05TDtBmLFCTF+hrwQ Dw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x0g4h00sh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Mar 2024 07:11:58 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 42L7BwbP010058 for ; Thu, 21 Mar 2024 07:11:58 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x0g4h00se-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Mar 2024 07:11:58 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 42L5aCM3015792; Thu, 21 Mar 2024 07:11:57 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3wwp50bmww-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Mar 2024 07:11:57 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 42L7BrgY44433856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Mar 2024 07:11:55 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 88CC120043; Thu, 21 Mar 2024 07:11:53 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 49A7420040; Thu, 21 Mar 2024 07:11:53 +0000 (GMT) Received: from li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com (unknown [9.171.56.65]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTPS; Thu, 21 Mar 2024 07:11:53 +0000 (GMT) Date: Thu, 21 Mar 2024 08:11:52 +0100 From: Stefan Schulze Frielinghaus To: David Malcolm Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] analyzer: Bail out on function pointer for -Wanalyzer-allocation-size Message-ID: References: <20240319151032.732309-2-stefansf@linux.ibm.com> <4d7e9b63b196951a2a0638909868e6258be8bf5e.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4d7e9b63b196951a2a0638909868e6258be8bf5e.camel@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: GfIn1gSShQBK7cLxVhUGR2v5UY4FNnLU X-Proofpoint-ORIG-GUID: hgSmA2sJjowwGef2we0vqRCyNCxLu7lV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-21_04,2024-03-18_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 suspectscore=0 mlxlogscore=999 clxscore=1015 malwarescore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 spamscore=0 phishscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403140000 definitions=main-2403210047 X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H4,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: On Tue, Mar 19, 2024 at 12:38:34PM -0400, David Malcolm wrote: > On Tue, 2024-03-19 at 16:10 +0100, Stefan Schulze Frielinghaus wrote: > > On s390 pr94688.c is failing due to excess error > > > > pr94688.c:6:5: warning: allocated buffer size is not a multiple of > > the pointee's size [CWE-131] [-Wanalyzer-allocation-size] > > > > This is because on s390 functions are by default aligned to an 8-byte > > boundary and during function type construction size is set to > > function > > boundary.  Thus, for the assignment > > > > a.0_1 = (void (*) ()) &a; > > > > we have that the right-hand side is pointing to a 4-byte memory > > region > > whereas the size of the function pointer is 8 byte and a warning is > > emitted. > > FWIW the test case in question is a regression test for an ICE seen in > the GCC 10 implementation of the analyzer, which was fixed by the big > rewrite in r11-2694-g808f4dfeb3a95f. > > So the code in the test doesn't make a great deal of sense. > > > > > I could follow and skip this test as done in PR112705, or we could > > bail > > out early in the analyzer for function pointers.  My intuition so far > > is that -Wanalyzer-allocation-size shouldn't care about function > > pointer.  Therefore, I went for bailing out early.  If you believe > > this > > is wrong I can still go by skipping this test on s390.  Any thoughts? > > I tried imagining a situation where we're analyzing a function > generated at run-time, but it strikes me that the buffer allocated for > such a function can be of arbitrary size. So -Wanalyzer-allocation- > size is meaningless for functions. > > There's probably a case for checking for mismatches between pointers to > code vs pointers to data (e.g. alignments, Harvard architecture > machines, etc), but -Wanalyzer-allocation-size doesn't do that. > > So I think your patch is correct. > > OK to push it if it passes bootstrap®ression testing. Bootstrapped and regtested on x64 and s390x. Thanks, Stefan > > Thanks > Dave > > > --- > >  gcc/analyzer/region-model.cc | 4 ++++ > >  1 file changed, 4 insertions(+) > > > > diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region- > > model.cc > > index f079d1fb37e..1b43443d168 100644 > > --- a/gcc/analyzer/region-model.cc > > +++ b/gcc/analyzer/region-model.cc > > @@ -3514,6 +3514,10 @@ region_model::check_region_size (const region > > *lhs_reg, const svalue *rhs_sval, > >        || TYPE_SIZE_UNIT (pointee_type) == NULL_TREE) > >      return; > >   > > +  /* Bail out early on function pointers.  */ > > +  if (TREE_CODE (pointee_type) == FUNCTION_TYPE) > > +    return; > > + > >    /* Bail out early on pointers to structs where we can > >       not deduce whether the buffer size is compatible.  */ > >    bool is_struct = RECORD_OR_UNION_TYPE_P (pointee_type); >