From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by sourceware.org (Postfix) with ESMTPS id 363DE399C02E; Thu, 22 Jul 2021 19:50:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 363DE399C02E X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [79.251.9.160] ([79.251.9.160]) by web-mail.gmx.net (3c-app-gmx-bap16.server.lan [172.19.172.86]) (via HTTP); Thu, 22 Jul 2021 21:50:41 +0200 MIME-Version: 1.0 Message-ID: From: Harald Anlauf To: Tobias Burnus Cc: fortran , gcc-patches Subject: Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169 Content-Type: text/plain; charset=UTF-8 Date: Thu, 22 Jul 2021 21:50:41 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <9b6187f0-d3dd-bb2d-d6f3-ada831cdecf0@codesourcery.com> References: <9b6187f0-d3dd-bb2d-d6f3-ada831cdecf0@codesourcery.com> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:SbtnX7y9uId2xJ22ZLrd/Brt5ST5zjNWInQenpJ9wMMnsoQyuHotxIRhJ6GsQxu+X75Pc AfSnk/sgtT6ccfQ5NdwbapSCsRybRIZtzSumrujCS9gQ+VSj7VYn4PnHxs5amLIKEE27qOdIuFrL qUlJoWNzUwNtFd5br9e18cntTm3unAixLurWif2iZFubFAXzmSUN0f08GAXs2X6UdpizsZGK/L/A J1Cg2nLjLmAEZhjd3zA5MMDPbQT5PDHijTQb3O0ywtwaCy84yyN0aO/d/0Vn8fi5akP1oawImK8B Ic= X-UI-Out-Filterresults: notjunk:1;V03:K0:Zz1B9qIX0mM=:d9EISHwTcHPxwxURBhf7Ie 1+oD0jRupVxQEPIcab4R2ANvX/MPYdCgt5myWzD6Pei11gue/LioDYVzD75yXLClRtU6JbDHF oXD5hJLj1EIZwzVEeAiDkx9jnD/8YFugmMbt+LRoq6WYYzRI27UBCQcxBY8e4aHmO1ExlHIej aRZA565zHB8q5uxLzENHT1kMilR2UnFCCGQyZyoTOB1qm/YoOAoPoSkpqQQ6DOHGWJTVgOhXJ ARAjyKFi3a2kL6aVgLpoHPZlfnMfdrUqsOc6KvRi2n5ocaFirhKmxiu8/h/TTn/EFQz6cPw/E gC3s+fqYOSPsQpFuPcSOzwAIQ+At5YuryrEQeHF4DeFOLr3W4evSORpIrAIqP1O+TE8/Rlcrb eyHERa8ESeZBHXqtxBtwet4hZ2Q6qmEofLwezPtwA2FoUqMCJxXycluIhaZ6hyns1hypwtVzi ygUry7JVvzSZ7cNf+wRfCtL53rqDAl145dBbBSLCMnl9UOQak7XZh58AzRqjGsmGtDqyMM9tf QGxgth+DcT7IXtostgGVjnMaGgvU16eq/Aa9J2f+RSNep/zVlDRibVvJIuxp45D5krX26Rp6+ +jTiV2mooU3QP6AbDijQ5mKUOIEMToUOcU+uzDuN2C6xzLGpLeCEmS6cMYSZhr6KRRIGmhVjA RqSFMTlfCsY4cLAxDMce5wrVQz/pvhEa11yuoKlJnAaAMmTsnE0j4AowdmzdIM979GYn01Wb0 HPcwPJreGvJsZCJxoD7eWc7H7JNRe8eBAxBn37WkXBvVe2Qhpanrd9zzHA/9sk5pEG74d+stc offFNWft2hKo6aiKrBCUIAI6jj/8g== X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 19:50:47 -0000 Hi Tobias, I am afraid we're really opening a can of worms here=2E=2E=2E=2E > Additionally, I wonder whether that will work with: >=20 > integer, pointer :: ptr > integer function f() > pointer :: f > f =3D ptr > end > allocate(A, stat=3Df()) >=20 > The f() is a variable and definable =E2=80=93 but I am currently not sur= e it sets stat->symtree > and not only stat->value=2Efunction=2Eesym, but I have not tested it=2E I think a "working" testcase for this could be: program p implicit none integer, target :: ptr integer, pointer :: A allocate (A, stat=3Df()) print *, ptr contains function f() integer, pointer :: f f =3D> ptr end function f end This works as expected with Intel and AOCC, but gives a syntax error with every gfortran tested because of match=2Ec: alloc_opt_list: m =3D gfc_match (" stat =3D %v", &tmp); where the comment before gfc_match states: %v Matches a variable expression (an lvalue) although it matches only variables and not every type of lvalue=2E We therefore never get to the interesting checks elsewhere=2E=2E=2E > Additionally, I have to admit that I do not understand the > following existing condition, which you did not touch: >=20 > if ((stat->ts=2Etype !=3D BT_INTEGER > && !(stat->ref && (stat->ref->type =3D=3D REF_ARRAY > || stat->ref->type =3D=3D REF_COMPONENT))= ) > || stat->rank > 0) > gfc_error ("Stat-variable at %L must be a scalar INTEGER " > "variable", &stat->where); >=20 > I mean the ts=2Etype !=3D BT_INTEGER and stat->rank !=3D 0 is clear, > but what's the reason for the refs? Well, that needs to be answered by Steve (see commit 3759634)=2E [=2E=2E=2E] > And possibly add a testcase for stat=3Df() [valid] > and stat=3Dx%y%kind [invalid] as well? Well, I need to go back to the drawing board then=2E=2E=2E Thanks, Harald