From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by sourceware.org (Postfix) with ESMTPS id 4A1AE385B805; Mon, 29 Nov 2021 20:21:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A1AE385B805 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gluon.fritz.box ([79.251.15.55]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M9o21-1munQB09vZ-005tRj; Mon, 29 Nov 2021 21:21:02 +0100 Subject: Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays To: Chung-Lin Tang , Fortran List , gcc-patches Cc: Tobias Burnus Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: From: Harald Anlauf Message-ID: Date: Mon, 29 Nov 2021 21:21:00 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ZDLWOJ9BduWFycbGi2djotXHTkAOXfaIt+b68+QIOpD1MRJXvyM /7WFKwi6ZRwHwnBkQW6bi/rDYbXrx9GfBVO8xRBItceNNJ/P9FjfDTtRPqBQ5a3SPJV1Joz N6mJiJ1kAnpeDzF1lYZ1W6TgHCiiwwpv0RacMmIY/8TG2QCOth/yZqxPT8b0VTuTxwQynw9 r9OJF4HKIbFU5kPVUAXqg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Pv2mCwMiFBc=:UDTvBkyfAmM9gQP42XUxlV xqw0+dd+HNcQ5vDzK69MCuB1Ji5ttK15tbQw6rIwLa2tnNdsdh750MFaZJc+6Hj3CEqa+tW7C mNVc+cvvEbrElJ8bBPYkchWL0mhrW9f1Sdsec1tFzvrSXNRqjmzPAy57NvsKaNWAfJdLvAZmU WnwaNxvyG+aI0kYI2h1lpvBf/K0JiJCK9aNauuToaaSZlDdGn4FTsCXT9Jev4IQM0JOqhakMg zJW8d2ulO79xDSdIU/5H+MfNxECOqjro90O2GHlH/bHOQMUCYENHW3GpFfILSGKcuo+7VaIK5 82rxqlkSbUI0Uk8WuES86IuwkDLhVO8N6ROHwCqAXgJ4G0H31GFLkJ2qkwMY6xqW3s1/WAzL5 Dy0yjXSfU1NQaiA3w8/T1fPj3+UfkpRLR9iZ37v9DL5xS1JPzQDuFJo6axLgKuTZu1/jcrBke NDW44mpaTXcpP2TDacPvRTRzYw1gBUxTxSAuNs5xKLl2zJZlGY/rj7LDZVMumHm9RDJtcVTA8 c1CCp5WkNrOBN/8n+opxtQ6ZSGKOg8GiJd8+cj2ItogaLVVNC+chjFHhA+Loi+OJXNTdXk3vP 8XY9cQwnU2FXEyw6gFwCTFY55KpGK41j2vTD/VF8DqbqHS6ajmeNzYmyNLGnOv/Ilbrw3BJga sewnai54Zzw0cudj2MjI/DdrpNbocFz9368X+9MGLCbvDb7cRdAM6jj8hxtRjIHrN91i810SM WCnK6konBcSBNGE20SGYTxUjcneETn7tom5d/4qnMvOQ8mA8cMewNE1puw31FwSxRx3iLR5P3 pdKcPNCjqQzHdzqAIXTSUTNw15UvDsL2+uqEw3Cv3SS9BDCd+dBhw/Ss/yXPKS1ubxd+pQkPj U9FtIyU4j7xf3qInJ2qn/71V0JNkm8E8xZ4bg1iU3h+2oONqeZU/Q2ztZGqq7GRbm87edS8pv vdOvsomjGO5gxwTafzt0DTZu/q7veKv0L0igDr4QKcN0LX3f2nUke4+/kwNgbWi4V833cK9Uj MEQXVHsowA55W6bwhIeZXlb3ixBSbQs+pC3rNl+nCjkCT6Xnt3zYRtUIeHSbAdQSKYLuIm+c+ 4FIi0nFFuD+rAk= X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, 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: Mon, 29 Nov 2021 20:21:11 -0000 Hi Chung-Lin, Am 29.11.21 um 15:25 schrieb Chung-Lin Tang: > This patch by Tobias, fixes a case of setting array low-bounds, found > for particular uses of SOURCE=3D/MOLD=3D. > > For example: > program A_M > =C2=A0 implicit none > =C2=A0 real, dimension (:), allocatable :: A, B > =C2=A0 allocate (A(0:5)) > =C2=A0 call Init (A) > contains > =C2=A0 subroutine Init ( A ) > =C2=A0=C2=A0=C2=A0 real, dimension ( 0 : ), intent ( in ) :: A > =C2=A0=C2=A0=C2=A0 integer, dimension ( 1 ) :: lb_B > > =C2=A0=C2=A0=C2=A0 allocate (B, mold =3D A) > =C2=A0=C2=A0=C2=A0 ... > =C2=A0=C2=A0=C2=A0 lb_B =3D lbound (B, dim=3D1)=C2=A0=C2=A0 ! Error: lb= _B assigned 1, instead of 0 > like lower-bound of A. > > Referencing the Fortran standard: > > "16.9.109 LBOUND (ARRAY [, DIM, KIND])" > states: > "If DIM is present, ARRAY is a whole array, and either ARRAY is > =C2=A0an assumed-size array of rank DIM or dimension DIM of ARRAY has > =C2=A0nonzero extent, the result has a value equal to the lower bound > =C2=A0for subscript DIM of ARRAY. Otherwise, if DIM is present, the > =C2=A0result value is 1." > > And on what is a "whole array": > > "9.5.2 Whole arrays" > "A whole array is a named array or a structure component ..." > > The attached patch adjusts the relevant part in gfc_trans_allocate() to > only set > e3_has_nodescriptor only for non-named arrays. > > Tobias has tested this once, and I've tested this patch as well on our > complete set of > testsuites (which usually serves for OpenMP related stuff). Everything > appears well with no regressions. > > Is this okay for trunk? I think you need to check the following: allocate(c, source=3Dh(3)) write(*,*) lbound(c,1), ubound(c,1) ! prints 1 3 ... pure function h(i) result(r) integer, value, intent(in) :: i integer, allocatable :: r(:) allocate(r(3:5)) r =3D [1,2,3] end function h This used to print 3 5, which is also what e.g. NAG, Nvidia, flang do. Intel prints 1 3, so it agrees with you. The Fortran standard has: 9.7.1.2 Execution of an ALLOCATE statement (6) When an ALLOCATE statement is executed for an array with no allocate-shape-spec-list, the bounds of source-expr determine the bounds of the array. Subsequent changes to the bounds of source-expr do not affect the array bounds. Please re-check with Tobias. Thanks, Harald > Thanks, > Chung-Lin > > 2021-11-29=C2=A0 Tobias Burnus=C2=A0 > > gcc/fortran/ChangeLog: > > =C2=A0=C2=A0=C2=A0=C2=A0* trans-stmt.c (gfc_trans_allocate): Set e3_has= _nodescriptor to true > =C2=A0=C2=A0=C2=A0=C2=A0only for non-named arrays. > > gcc/testsuite/ChangeLog: > > =C2=A0=C2=A0=C2=A0=C2=A0* gfortran.dg/allocate_with_source_26.f90: Adju= st testcase. > =C2=A0=C2=A0=C2=A0=C2=A0* gfortran.dg/allocate_with_mold_4.f90: New tes= tcase. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id C56FF3858409 for ; Mon, 29 Nov 2021 20:21:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C56FF3858409 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mrn9B-000A10-Gv for gcc-patches@gcc.gnu.org; Mon, 29 Nov 2021 21:21:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays Date: Mon, 29 Nov 2021 21:21:00 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: Content-Language: en-US Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, 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: Mon, 29 Nov 2021 20:21:13 -0000 Message-ID: <20211129202100._mHnnvTUFOZ41MJ_4cdyEeHannPp1dTY_CDepRZo3Q8@z> Hi Chung-Lin, Am 29.11.21 um 15:25 schrieb Chung-Lin Tang: > This patch by Tobias, fixes a case of setting array low-bounds, found > for particular uses of SOURCE=/MOLD=. > > For example: > program A_M >   implicit none >   real, dimension (:), allocatable :: A, B >   allocate (A(0:5)) >   call Init (A) > contains >   subroutine Init ( A ) >     real, dimension ( 0 : ), intent ( in ) :: A >     integer, dimension ( 1 ) :: lb_B > >     allocate (B, mold = A) >     ... >     lb_B = lbound (B, dim=1)   ! Error: lb_B assigned 1, instead of 0 > like lower-bound of A. > > Referencing the Fortran standard: > > "16.9.109 LBOUND (ARRAY [, DIM, KIND])" > states: > "If DIM is present, ARRAY is a whole array, and either ARRAY is >  an assumed-size array of rank DIM or dimension DIM of ARRAY has >  nonzero extent, the result has a value equal to the lower bound >  for subscript DIM of ARRAY. Otherwise, if DIM is present, the >  result value is 1." > > And on what is a "whole array": > > "9.5.2 Whole arrays" > "A whole array is a named array or a structure component ..." > > The attached patch adjusts the relevant part in gfc_trans_allocate() to > only set > e3_has_nodescriptor only for non-named arrays. > > Tobias has tested this once, and I've tested this patch as well on our > complete set of > testsuites (which usually serves for OpenMP related stuff). Everything > appears well with no regressions. > > Is this okay for trunk? I think you need to check the following: allocate(c, source=h(3)) write(*,*) lbound(c,1), ubound(c,1) ! prints 1 3 ... pure function h(i) result(r) integer, value, intent(in) :: i integer, allocatable :: r(:) allocate(r(3:5)) r = [1,2,3] end function h This used to print 3 5, which is also what e.g. NAG, Nvidia, flang do. Intel prints 1 3, so it agrees with you. The Fortran standard has: 9.7.1.2 Execution of an ALLOCATE statement (6) When an ALLOCATE statement is executed for an array with no allocate-shape-spec-list, the bounds of source-expr determine the bounds of the array. Subsequent changes to the bounds of source-expr do not affect the array bounds. Please re-check with Tobias. Thanks, Harald > Thanks, > Chung-Lin > > 2021-11-29  Tobias Burnus  > > gcc/fortran/ChangeLog: > >     * trans-stmt.c (gfc_trans_allocate): Set e3_has_nodescriptor to true >     only for non-named arrays. > > gcc/testsuite/ChangeLog: > >     * gfortran.dg/allocate_with_source_26.f90: Adjust testcase. >     * gfortran.dg/allocate_with_mold_4.f90: New testcase.