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 175C93858414; Tue, 30 Nov 2021 19:54:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 175C93858414 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gluon.fritz.box ([79.251.4.183]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M4JmN-1msQBz2Civ-000N1Y; Tue, 30 Nov 2021 20:54:38 +0100 Subject: Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays To: Tobias Burnus , Chung-Lin Tang , Fortran List , gcc-patches Newsgroups: gmane.comp.gcc.fortran,gmane.comp.gcc.patches References: <3ff664cf-c928-6179-d0d4-728401987264@codesourcery.com> <79ac1a54-7959-2aca-1ecb-2237155752b8@codesourcery.com> From: Harald Anlauf Message-ID: Date: Tue, 30 Nov 2021 20:54:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <79ac1a54-7959-2aca-1ecb-2237155752b8@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:nydD2GwPG/7PFdK1JRoDijFCXqpPQAYnsjXlgF+qMN386cF8GYK aqR7c0Gzad0GrR58T4acf5iaPcz7wSPGgCXK3hMKJGoYUm/bNzY1TsN9Zxj260mL5XIWXWs 9wkM2WaEmWQOkBaz61v0RLNYJVSRyC0Jx+rSKnUg+oLxlO7a772cQlNTRoYFUtdt8jTlDOT LbPKtEbbuRFQiBqYRT/jA== X-UI-Out-Filterresults: notjunk:1;V03:K0:r2wPuOAZHeI=:D8M4cYYsj2GFz6rQbl1N+a MjmsBJ9X7Zwra6Lxk0ct4M/876r3/RPdFjidEtklvis8QsO+PobntWFiQMb/o8PAH/dmwJi/L 7Pn1Z8AnKAleeGO6b+7Ouu0BrByZ/iHuhZPaBvJYAHy4Ao2cpiAX+AOD0HW8oqLYSSOPW4goU A7haw+0UB67I/8sQsxopwuIEJx802JNmywQ6r8NJ5Qzg/R6XyO96bX7/6DrqiMmAusp+ixuxu CVHCpFVnhf0ymjfgEud1gNNhjFjr4m69d4/05bACEu5rDapUS13BGgJSzPEzyF2Mypmvz0Ksl aU8vNBnWpoU1h0B3RKYKJgipNCfX5sRpHy6DyHV1bLK0w9wp0tbwhEYpbsbD+qDmqMiviaLw0 Q1mFrFQoRkBYiWF6q+rHa05xY1dCZtlpz3Kxs+weJSPAsGiipw2Ag/pG8Lh1wDmeqp3BLqjCO q5FlauEv5HinsAZpNNUJ3RaIAa/vXGAybPu0W8eCLYoAg8rfpCLfzqfTrBH4u0YoNtShtrCw2 HQqgi/vTaxsCKHfelidRU7zsDqsYS7kU27wadt+pZcTE1mSzuYxrrrOeXz1sfKCQhFBIxk9UE x8KtI5jBHV4J+/m/mYreAa53fjePrIbWfuZlwldySEARuJItjsHBsV+G0h6yHJL2zjrZb4+p2 mDJz87EyCNj5NaQ4OdjVNqbqVccVHKGM7oJni+b8LaTfZa6/R3ar+KfpvDUhpbuoBfAcE+lP7 TdymxjVaKjEG4+8E9X1Apu8RoqPXuN49hNf8vm7HvyCmJTQ/7HoDfTripUBa273pxx2fjJ2FJ KdlXhbFkbMWY0tq8ULxtEnaOBBuexdmze612/pl/n5c//suqG9KZZNY4F58dvqpcX4DpBKFOo a2rqg9r2fVgpbBR3OHQJzIcxfAAeoflqsHqwzDEn7MdxnFksDO0oYk3MvI6j5TP6C+pBKf6LF oKwYAS7waKHrd/Hp6Ric8itSBnjYsFgQK08ybdokYCNymW+x7gam2hGFr72sFs7h43aLT5WL7 WCVxLd6I1o2GLc7ioTs/JCQkx7hJD82sljXnLeVFrAtDkUkajbi1uFuFBKKVFpxb+w== X-Spam-Status: No, score=-6.0 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 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: 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: Tue, 30 Nov 2021 19:54:45 -0000 Hi Tobias, Am 30.11.21 um 18:24 schrieb Tobias Burnus: > On 29.11.21 22:11, Harald Anlauf wrote: > >>> "A whole array is a named array or a structure component whose final >>> part-ref is an array component name; no subscript list is appended." >>> >>> I think in "h(3)" there is not really a named array =E2=80=93 thus I r= ead it as >>> if the "Otherwise ... result value is 1" applies. >> >> If you read on in the standard: >> >> "The appearance of a whole array variable in an executable construct >> specifies all the elements of the array ..." >> >> which might make you/makes me think that the sentence before that one >> could need an official interpretation... > > I am not sure whether I understand what part of the spec you wonder > about. (I mean besides that 'variable' can also mean referencing a > data-pointer-returning function.) strictly speaking you're now talking about the text for LBOUND, and your quote is not from the standard section about the ALLOCATE statement. And there are several places in the standard document where there is an explicit reference to LBOUND when talking about what the bounds should be. This is why I am unhappy with the text about ALLOCATE, not about LBOUND. > Question: What do NAG/flang/... report for lbound(h(3)) - also [3] =E2= =80=93 or > [1] as gfortran? > >> I've submitted a reduced example to the Intel Fortran Forum: >> https://community.intel.com/t5/Intel-Fortran-Compiler/Allocate-with-SOU= RCE-and-bounds/m-p/1339992#M158535 >> >> >> >> There are good chances that Steve Lionel reads and comments on it. > > So far only "FortranFan" has replied =E2=80=93 and he comes to the same > conclusion as my reading, albeit without referring to the standard. You seem to be quite convinced with your interpretation, while I am simply confused. So go ahead and apply to mainline. Let's see if we learn more. I do hope I will. 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 >