[J3] ALLOCATE with source-expr determining the array bound & resulting lower bound
Van Snyder
van.snyder at sbcglobal.net
Wed Dec 1 04:58:58 UTC 2021
On Wed, 2021-12-01 at 11:11 +0900, Malcolm Cohen via J3 wrote:
> No.
>
> A function result can be an ALLOCATABLE variable. That is within the
> function itself.
>
> Outside the function, there is no result variable, we just have the
> value. It is not a variable, let alone an allocatable one.
15.5.3 says the value of the function result gets its characteristics
from the interface. It doesn't say "except whether it is allocatable."
15.3.3 says "whether it is allocatable" is a characteristic of the
function result. How can the value of the function result not be
allocatable?
I agree that it's not a variable, but it is somehow deallocated after
it's used as the expr in an assignment statement, an actual argument,
item in an output list, a selector in an associate construct, the case-
expr in a CASE construct, ....
If you want an allocatable variable from the value of a function with
an allocatable result value, without copying it, you can use it as the
FROM argument in MOVE_ALLOC.
The value of a function result cannot be subscripted, so it's difficult
to imagine how it's not a whole array, notwithstanding its absence from
the definition.
> The standard’s definition of “whole array” and LBOUND are correct.
>
> Cheers,
> --
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>
> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Van Snyder
> via J3
> Sent: Wednesday, December 1, 2021 10:33 AM
> To: Steidel, Jon L <jon.l.steidel at intel.com>; j3 <j3 at j3-fortran.org>
> Cc: Van Snyder <van.snyder at sbcglobal.net>
> Subject: Re: [J3] ALLOCATE with source-expr determining the array
> bound & resulting lower bound
>
> On Tue, 2021-11-30 at 23:41 +0000, Steidel, Jon L wrote:
> > I believe the point Tobias was making is the definition of LBOUND
> > states:
> >
> > RESULT VALUE.
> >
> > Case (i): 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 is 1.
> > Case(ii): LBOUND (ARRAY) has a value whoseith
> > element is equal to LBOUND (ARRAY, i), for i = 1, 2, . . .,n, where
> > n is the rank of ARRAY.
> > LBOUND (ARRAY, KIND=KIND) has the
> > value whoseith element is equal to LBOUND (ARRAY, i, kind), for i =
> > 1, 2, . . . ,n, where
> > n is the rank of ARRAY.
> >
> > Whole array is defined as:
> > array component or array name without further
> > qualification
> >
> > h(3) is a function result, which is not an array component or array
> > name. Therefore, the “otherwise” in Case (i) applies, and the
> > lower bound of c is 1.
>
> As Tobias wrote, 9.7.1.2p6 says that when an array is allocated with
> no allocate-shape-spec-list, the bounds of the allocated object are
> those of the source-expr. It doesn't say LBOUND and UBOUND of the
> source-expr.
>
> 15.3.3 says that "whether it is allocatable" is a characteristic of a
> function result. 15.5.3 says that the characteristics of the value of
> a function result are "determined by the interface of the function."
> I interpret that to include "whether it is allocatable" as a
> characteristic of the value of a function result. Therefore, the
> lower bound of the value of h(3) ought to be 3, and therefore the
> lower bound of c ought to be 3.
>
> The question Tobias asked was "what are the bounds for c" and
> illustrated how he had asked processors' opinions using LBOUND(c,1)
> and UBOUND(c,1). In those references, c is a whole array, not a
> function result. Its bounds should be the same as the bounds of h(3).
>
> Whether LBOUND(h(3),1) ought to be 1 or 3 depends upon the definition
> of "whole array."
>
> It looks like the definition of "whole array" ought to include
> function results. One cannot subscript a function result, so the
> result cannot be anything
> other than the entire array.
>
> Does resolving the value of LBOUND(h(3),1) need an interp?
>
> >
> > From: J3 <j3-bounces at mailman.j3-fortran.org>On Behalf Of Van Snyder
> > via J3
> > Sent: Tuesday, November 30, 2021 5:10 PM
> > To: General J3 interest list <j3 at mailman.j3-fortran.org>
> > Cc: Van Snyder <van.snyder at sbcglobal.net>; Harald Anlauf <
> > anlauf at gmx.de>; Chung-Lin Tang <cltang at codesourcery.com>
> > Subject: Re: [J3] ALLOCATE with source-expr determining the array
> > bound & resulting lower bound
> >
> > On Tue, 2021-11-30 at 21:41 +0100, Tobias Burnus via J3 wrote:
> > > Hello J3,
> > >
> > > I have a question regarding the following which came up for GCC.
> > >
> > > * NAG, Nvidia, flang yield a lower bounds of 'c' of 3 in the
> > > following example.
> > > * ifort gives a lower bound of 1
> > > * When fixing a related issue, GCC is about to change from 3 to 1
> > > as collateral change.
> > >
> > > However, my question is which value is the proper lower bound
> > > of 'c' for:
> > >
> > > implicit none
> > > integer, allocatable :: c(:)
> > > allocate(c, source=h(3))
> > > write(*,*) lbound(c,1), ubound(c,1)
> > > contains
> > > 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
> > > end
> > >
> > >
> > > 18-007r1 [134:27-29] has the following (and 21-007r2 [144:3-5]
> > > likewise):
> > > "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."
> > >
> > > Unless I missed something, the standard never quite says what the
> > > bounds of an expression is. For the lower bound, I see it at two
> > > places: In the LBOUND intrinsic itself – and at several places in
> > > the standard, there is wording like the following (here for the
> > > intrinsic assignment, 10.2.1.3, [161:17-18]):
> > > "the shape of expr with each lower bound equal to the
> > > corresponding
> > > element of LBOUND (expr) if expr is an array."
> > >
> > > I do not see such wording for the ALLOCATE with the source-expr
> > > and wonder whether it is missing.
> > >
> > >
> > > Assuming the LBOUND rules apply, there is in 16.9.109 LBOUND
> > > [384:29-31]:
> > > 'ARRAY is a whole array, and ... Otherwise, if DIM is present,
> > > the result
> > > value is 1.'
> > >
> > > 9.4.2 defines 'A whole array is a named array or a structure
> > > component whose final part-ref is an array component name ...'
> > > [127:6-7]
> > >
> > > And my reading is that h(3) returns an array but that one is
> > > not named;
> > > thus, in my reading lbound(h(3),1) = 1. – And, using the LBOUND
> > > connection,
> > > I infer lbound(c,1) = 1.
> > >
> > > First question: Have I missed something?
> > > Second question: Is some LBOUND wording needed for source-expr?
> > >
> > > Tobias
> >
> > The result value of h(3) is allocatable and therefore its bound(s)
> > are the ones specified when it was allocated (15.3.3, 15.5.3). I
> > would expect the lower bound of h(3) to be 3, and the lower bound
> > of c to be 3.
> >
> > If the allocate statement were changed to
> >
> > allocate ( c, source = ( h(3) ) ) then the lower bound would be 1
> > because ( h(3) ) is not an allocatable object.
> >
> > I remember reading something about an allocatable result of a
> > function not being deallocated until after the result is used, for
> > example as the <expr> in an assignment, an item in an output list,
> > an actual argument, ..., but I can't find it now.
> >
>
>
> Disclaimer
> The Numerical Algorithms Group Ltd is a company registered in England
> and Wales with company number 1249803. The registered office is: 30
> St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy
> Notice for information on how we process personal data and for
> details of how to stop or limit communications from us.
>
> This e-mail has been scanned for all viruses and malware, and may
> have been automatically archived by Mimecast Ltd, an innovator in
> Software as a Service (SaaS) for business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20211130/d4cc3998/attachment-0001.htm>
More information about the J3
mailing list