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 D40F13858D28; Mon, 10 Jun 2024 07:19:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D40F13858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D40F13858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.15.15 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718003952; cv=none; b=xSWS2XOLMiErlN2iXE31gOt36UlIOyySm2tyLHTfIwj40v31oF24HZPdlyqLemZGCmyiS6fPjskDn9Ak23LDrq90B7wm28sSdUcT3pIQ3+flkt9pIx/ElAw94tGrxPaUAk4L1jVsbYAjiPOt4vZmifTghL5pfFPT80Gy0LVUXOY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718003952; c=relaxed/simple; bh=oRnmVsuiXExpiYAt4vQmYdDDJZh++qYFQ7+qky8zKUk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=l0KrvyPkQGVcHmP/lUp19bwQCRFWqlbaEPlpevFHbu3v/BBC1HgkevO8gUtVtjs178yQYq36SQ35e9D99ssEPRlU2g2Xjc6Bgc7GH5yT3s/MBjV/LfdOu/Te62Zrz3G/1JBzQJxhkJ6WyS8/6Kyg7fmKV/JCsAc0H4txs3upGvk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1718003948; x=1718608748; i=vehre@gmx.de; bh=DDSo6Fjiy6ZJ/nuuGee7WvOGsuUyOsoCZ6Tamg5qYno=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=cp7GNmf1nrRAVUlFMWO/GJ3af6ELQ0/o1aKDCY8PV7fQyRhW89/vqJ1q3HpEImdB A0tf5Xn9++b/9MRlIFw0c0K6cUZRN8jl7x+umhkWBTNOT/Pby6hIPCWPF+J+LVmKo hr6mDL+fl3BCwOhIyHPRgaEjZ0PskwV5fecxuE8fvSJRBl1NumEWdmahgauKIwhIL RV2qGNSYqG/zv2uMkacqXmVnjBxqpfWS0yJUeHIkc52OKy+bYY4bbEU8IWvlbsvOy tQcpy9sQ9l4hOm0cAecmNOXRP7atLKD8Arpu4xGgBmNX8lUGs1xZNcd1Upf9FkJz7 ulkuCZ3hK3neDs5M5g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from vepi2 ([62.155.205.192]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N6sn7-1sUVLo2Ztn-016Vgw; Mon, 10 Jun 2024 09:19:07 +0200 Date: Mon, 10 Jun 2024 09:19:06 +0200 From: Andre Vehreschild To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches Subject: Re: [Patch, fortran] PR59104 Message-ID: <20240610091906.1295ae8d@vepi2> In-Reply-To: References: X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8DgujgU7IBFwIfdSCScf813HM0KZkneHOaCzZO121gUHQsULeXw YX24r8H36DpKEFr8Sbrr4Hj0XyCREV8qcJ5Y6SCwWhc810QrGl1rdYoI/5aCEfOnD7qUu1n kYSBlGecTvnyMeUcUx10GxO/UMxTG960o2RAImCDTB0k3w0qIP1MUDQRw/9PFhWXP9JKtlV N7mLbdp/qhlO/xclXQrTg== UI-OutboundReport: notjunk:1;M01:P0:FqbpR9TMGKg=;xr+/buLGv7OnBuzl88xtdnmLrzX 6lGGb7Bxc5j/j/+kIlozWGN3SvUrj9nC9P6z0naPb1clGpVU6HV6LDY+mthtcnkMV/uM+d5TN kG++0I5g30c6gZYlUZ8ACUp2Qn10P5bcM7SjdOaZw+k2PkrwpF4y1RD3szEj/vQdVJKBuSBtV gGJCkf7O0Ax+vc4dRl/R9c6Ijk/Y6ydBMB84MmGsdcLd8m3nEiM5vG5lTmxIe1/d5a7aEwcUk E8W91geMD3JVFMIe/3VqyJFuB088IL7YVu/4A+9nvup+/OIb9uOx9h+AwebGo+YTM3n1/izJs HBHn8E6it6Rmon7y8DH/lMH9tGlcp5a36TXLbedTLcadssMTiWEkTVbXRof6tCSHDozKZgFlq ZffMUr6MvyhQ6C1+Rvo24TNKcFMiHC7KC3IHB7W40wdDfD9CHpYLmQ2XMnHwmgfD/SBuH8zvX uz3ScxlmAp+lFLJOFwWRExllgeEoXsVSxJx6xbDinVePR8xhostnfBxwCeWxQQ+7X5WX3r5C3 MlMTQ6sprxKy1ByuZXMq+XiPwC1fo0kehgWHnndvOawQcoJwjOgB4qIkSE5GOLhILbuE4Z3eZ xVF4CrlEH4pkynOHqL59ahICIDi2J66PQ8A3sd6r4LnnxiRkJkugaT76Esfz1WbaklAK81rjs mGsPh4qDeRvGX8REuzv/ha9lJelsCg4ako8/EWvGK6mlGtEqiKIQvEuhDFJq9Uyr29vUfl0K0 gEKOWAK3ME/EbpJWEA4TZ9h10jhsJLlnCITSygvwHgDAaf8oCYw6Vt8MB8djP9V0IYD7fneKi 8KmV6eWlndyhRyTfasjn3AWdYWNvP4FY97Jo2ofpS3NNQ= X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Paul, while looking at your patch I see calls to gfc_add_init_cleanup (..., back= ), while the function signature is gfc_add_init_cleanup (..., bool front). Th= is slightly confuses me. I would at least expect to see gfc_add_init_cleanup(= ..., !back) calls. Just to get the semantics right. Then I wonder why not doing: diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc index bafe8cbc5bc..97ace8c778e 100644 =2D-- a/gcc/fortran/dependency.cc +++ b/gcc/fortran/dependency.cc @@ -2497,3 +2497,63 @@ gfc_omp_expr_prefix_same (gfc_expr *lexpr, gfc_expr *rexpr) return true; } + + +/* gfc_function_dependency returns true for non-dummy symbols with depend= encies + on an old-fashioned function result (ie. proc_name =3D proc_name->resu= lt). + This is used to ensure that initialization code appears after the func= tion + result is treated and that any mutual dependencies between these symbo= ls are + respected. */ + +static bool +dependency_fcn (gfc_expr *e, gfc_symbol *sym, + int *f ATTRIBUTE_UNUSED) +{ + return (e && e->expr_type =3D=3D EXPR_VARIABLE + && e->symtree + && e->symtree->n.sym =3D=3D sym); +} Instead of the multiple if-statements? + +bool +gfc_function_dependency (gfc_symbol *sym, gfc_symbol *proc_name) +{ + bool front =3D false; + + if (proc_name && proc_name->attr.function + && proc_name =3D=3D proc_name->result + && !(sym->attr.dummy || sym->attr.result)) + { + if (sym->as && sym->as->type =3D=3D AS_EXPLICIT) + { + for (int dim =3D 0; dim < sym->as->rank; dim++) + { + if (sym->as->lower[dim] + && sym->as->lower[dim]->expr_type !=3D EXPR_CONSTANT) + front =3D gfc_traverse_expr (sym->as->lower[dim], proc_name, + dependency_fcn, 0); + if (front) + break; + if (sym->as->upper[dim] + && sym->as->upper[dim]->expr_type !=3D EXPR_CONSTANT) + front =3D gfc_traverse_expr (sym->as->upper[dim], proc_name, + dependency_fcn, 0); + if (front) + break; + } + } + + if (sym->ts.type =3D=3D BT_CHARACTER + && sym->ts.u.cl && sym->ts.u.cl->length + && sym->ts.u.cl->length->expr_type !=3D EXPR_CONSTANT) + front =3D gfc_traverse_expr (sym->ts.u.cl->length, proc_name, + dependency_fcn, 0); This can overwrite a previous front =3D=3D true, right? Is this intended? + } + return front; + } The rest - besides the front-back confusion - looks fine to me. Thanks for= the patch. Regards, Andre On Sun, 9 Jun 2024 07:14:39 +0100 Paul Richard Thomas wrote: > Hi All, > > The attached fixes a problem that, judging by the comments, has been loo= ked > at periodically over the last ten years but just looked to be too > fiendishly complicated to fix. This is not in small part because of the > confusing ordering of dummies in the tlink chain and the unintuitive > placement of all deferred initializations to the front of the init chain= in > the wrapped block. > > The result of the existing ordering is that the initialization code for > non-dummy variables that depends on the function result occurs before an= y > initialization code for the function result itself. The fix ensures that= : > (i) These variables are placed correctly in the tlink chain, respecting > inter-dependencies; and (ii) The dependent initializations are placed at > the end of the wrapped block init chain. The details appear in the > comments in the patch. It is entirely possible that a less clunky fix > exists but I failed to find it. > > OK for mainline? > > Regards > > Paul =2D- Andre Vehreschild * Email: vehre ad gmx dot de