From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by sourceware.org (Postfix) with ESMTPS id 921933858430; Mon, 7 Mar 2022 19:58:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 921933858430 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.29] ([93.207.84.139]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJmGZ-1nlKFn1XWD-00KAOe; Mon, 07 Mar 2022 20:58:10 +0100 Message-ID: <7db8ae11-fd88-3ac6-e9fe-c8257e23bf6e@gmx.de> Date: Mon, 7 Mar 2022 20:58:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430] Content-Language: en-US To: Tobias Burnus , gcc-patches , fortran Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <2cd2f3b9-3b67-dc5f-de37-94c9c5002e53@codesourcery.com> From: Harald Anlauf In-Reply-To: <2cd2f3b9-3b67-dc5f-de37-94c9c5002e53@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:3DVlcnRpohfLm/ZK1O4jnIKfD7Ge9Zu/MUH/9I8ASmrkX6BBqBk qaFh0SHpeRVH7GTSbuhlXn6ticbPcqqCLaOoJhtd+hqq6/8tfSfmhoVXSfCufLBD4LKCnRj H33RLA4zniyX+BqvoSTliVHMPWWPkvbWWzKDzh16zKyaQnVfcybh/4LvxfFpjm8lpuqGG6N Ulr4wKqm570SggMtHxrkA== X-UI-Out-Filterresults: notjunk:1;V03:K0:TNbgoWRavTs=:fvHmYo7QtFGiwRNHGQLr4z C9N4KSWhN9vMHHkShetD2+QwM5wIviLkyle05vf9WPenSoDhFQbCEteszyY+ya8ZzPTSq1Jg/ /F7v6XeIY2X39tsZ6oifnxoKShBzJ3YFTc099Fr+COwDRwvWvr4nptH8FoH7p3gZaFot+Xu3O XXWneOzqLfELVpAJCSvkWHVg3MmtbFSLrM+Xm0Ah555qAQzjTED4Stx3OTZba5cCDiSauBynN vQaFwfhm+8XSPuDRoPci88Bqu6yHdfRHJDU4K3IQ62QmqB8mKKZ1Pmuz58Nrvp1gSp7EdQsA2 CCrfnoDo3m1EUY5tIqeEn1l/8UT+5jjjuP58DpyJlxHE6VzaVsSKb0OYE3oS53eTXZd29Dnff nARsQkf1FY1kbNjyOsUUkbbN5Ls+sboyg7iTASgVktrcKM00t83ifjrKbxb3XujM2qE8mWwa9 QbWSWE4Dz4xDyT1hWzN5DkoPQOQOoHW8PNWB14TK4eIVuyDvwTf9SoqGSkW6UT33JM2oPXpLE WjGRWRH+CHZE0JVxdGFVHJunh1FuQFf5js3whgIK+Ak4IfYRhTyLOZCKLgcuef8Q6WB6AgLPy mBg9NhTZ33ECm922jLiLVwwT0Px+bgIx+RuUi5ZdTeUHzVS4yx1B210TJ2ToEzDE7GvuLmDaS ryNeVnMY+z5jIAtnSc6rCE9vMAlXdrB8+z/4nTI/0THiMPnqhK6j2KDLGbwQ3m886m+XqERSw WbCaey5OFCbHc5HVdZSNOozAWBy9pfOFmT8o6St5yb1vQEdFu4MBOq4BGgLfophJ/nRIqB9Ls foo8jEv+QubG9i5WEclUSetPfc22JnkiOSLCM4WIbZLKrLWo5+DD1AVQo5hclLCdcerUR0awB mqghETsfRXLFlvoqwPQvn/fjt7KRo2njI2n3UbTxIpBgsXGsB7x4ZckeMklCf8Tt0wqDw5Y8Z sPbPVv5IksBm+pvF/NZWTnPMrDKHIWNksZDq83IDh4tkaw6CIGilFuyCYBzXm3fxDKuNN1FJJ 95827koupEtcmlAc9iOVm2LFShf02aF7qyRl6sC6i60S75AnZWi5wuYoC4UFB2sOTw== X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 19:58:17 -0000 Hi Tobias, Am 07.03.22 um 15:01 schrieb Tobias Burnus: > The problem is that inside the main program, > =C2=A0 y =3D f(z) > where the the result of z is > =C2=A0 type(t) :: z(size(x%a)) > and 'x' is a dummy argument. > > 'x' looses the attr.dummy in gfc_add_interface_mapping > and this leads to an additional indirect ref in > gfc_maybe_dereference_var - but after the first indirect > ref, TREE_TYPE is alread a RECORD_TYPE ... > > The simple fix is to simply punt when the argument > is not a pointer or reference. > > This patch additionally fixes a comment in > conv_parent_component_references. LGTM. Regarding the commit message, there should be a period at the end of > (gfc_maybe_dereference_var): Avoid derefereing a nonpointer I think there are other PRs which profit from this fix. Can you please have a look at PR99585, and in particular the link in comment#0? ;-) > Those parts are obvious. The only potentially risky > change is the comparison change from a name-wise comparison > to a pointer-based comparison. I think it is fine and the > testsuite did not find any issue, but you prefer, I can > also exclude it. I was thinking about this, too. But your change will prevent running into trouble in the (unlikely?) case c being a NULL pointer. > OK for mainline? How about GCC 10/11 backports? > (I think leaving out the last change, it should be very safe to do.) OK, as this is both an ICE-on-valid and a regression. Thanks for the patch! Harald > Tobias > ----------------- > 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 Gesellschaft: M=C3=BCnchen; > Registergericht M=C3=BCnchen, HRB 106955