From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 54ECE392B12E for ; Wed, 7 Dec 2022 10:08:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54ECE392B12E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.96,225,1665475200"; d="scan'208";a="88805705" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 07 Dec 2022 02:08:51 -0800 IronPort-SDR: CdQX+zghXHeWoBurd882Tw/ijs3vP4QD5dWcts49RuPCPWyUjfPZzW9I1N0E9OxnXGpnwPdFZq 9ydBAJNeW+vlpWgPT+th4ab7IGtix9X22NM8AhsnLRxxc+dr35IMX/0LbsSyNnWm6yGlhagjRh 9pOe5im1IDnB1TZkJPPqXhFXPf90FK53hwgyoyJks7BSYSLXlqMSGIxHw21kY+t5+r0bxNPGLW rbdGrVjS093gKNKXzDNvuCCmzukucog+5ww2jjWMC0kDX9Zx6B82X+IgCRotHn3zf8lDsU0D0K eMI= From: Thomas Schwinge To: Andrew MacLeod CC: Subject: Re: [PATCH] Fix a few incorrect accesses. In-Reply-To: References: User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Wed, 7 Dec 2022 11:08:40 +0100 Message-ID: <87359r34rb.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,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: Hi Andrew! On 2022-12-02T09:12:23-0500, Andrew MacLeod via Gcc-patches wrote: > This consists of 3 changes which stronger type checking has indicated > are non-compliant with the type field. I'm curious what that "stronger type checking" is? Gr=C3=BC=C3=9Fe Thomas > I doubt they are super important because there has not been a trap > triggered by them, and they have been in the source base since sometime > before 2017. However, we should probably fix them. > > I also notice that those are all uses of VOID_TYPE_P, which > coincidentally does not check if its a type node being checked: > > /* Nonzero if this type is the (possibly qualified) void type. */ > #define VOID_TYPE_P(NODE) (TREE_CODE (NODE) =3D=3D VOID_TYPE) > > So I guess it wouldn't trap anyway, just silently never trigger. > > Bootstraps on x86_64-pc-linux-gnu with no regressions. OK for trunk? > > Andrew > From d1003e853d1813105eef6e441578e5bea9de8d03 Mon Sep 17 00:00:00 2001 > From: Andrew MacLeod > Date: Tue, 29 Nov 2022 13:07:28 -0500 > Subject: [PATCH] Fix a few incorrect accesses. > > This consists of 3 changes which stronger type checking has indicated > are incorrect. > > gcc/ > * fold-const.cc (fold_unary_loc): Check TREE_TYPE of node. > (tree_invalid_nonnegative_warnv_p): Likewise. > > gcc/c-family/ > * c-attribs.cc (handle_deprecated_attribute): Use type when > using TYPE_NAME. > --- > gcc/c-family/c-attribs.cc | 2 +- > gcc/fold-const.cc | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc > index 07bca68e9b9..b36dd97802b 100644 > --- a/gcc/c-family/c-attribs.cc > +++ b/gcc/c-family/c-attribs.cc > @@ -4240,7 +4240,7 @@ handle_deprecated_attribute (tree *node, tree name, > if (type && TYPE_NAME (type)) > { > if (TREE_CODE (TYPE_NAME (type)) =3D=3D IDENTIFIER_NODE) > - what =3D TYPE_NAME (*node); > + what =3D TYPE_NAME (type); > else if (TREE_CODE (TYPE_NAME (type)) =3D=3D TYPE_DECL > && DECL_NAME (TYPE_NAME (type))) > what =3D DECL_NAME (TYPE_NAME (type)); > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc > index 114258fa182..e80be8049e1 100644 > --- a/gcc/fold-const.cc > +++ b/gcc/fold-const.cc > @@ -9369,8 +9369,8 @@ fold_unary_loc (location_t loc, enum tree_code code= , tree type, tree op0) > && TREE_CODE (tem) =3D=3D COND_EXPR > && TREE_CODE (TREE_OPERAND (tem, 1)) =3D=3D code > && TREE_CODE (TREE_OPERAND (tem, 2)) =3D=3D code > - && ! VOID_TYPE_P (TREE_OPERAND (tem, 1)) > - && ! VOID_TYPE_P (TREE_OPERAND (tem, 2)) > + && ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 1))) > + && ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 2))) > && (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 1), 0)) > =3D=3D TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 2), 0)= )) > && (! (INTEGRAL_TYPE_P (TREE_TYPE (tem)) > @@ -15002,7 +15002,7 @@ tree_invalid_nonnegative_warnv_p (tree t, bool *s= trict_overflow_p, int depth) > > /* If the initializer is non-void, then it's a normal expression > that will be assigned to the slot. */ > - if (!VOID_TYPE_P (t)) > + if (!VOID_TYPE_P (TREE_TYPE (t))) > return RECURSE (t); > > /* Otherwise, the initializer sets the slot in some way. One commo= n > -- > 2.38.1 ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955