[J3] FW: ALLOCATE with source-expr determining the array bound & resulting lower bound

Wed Dec 1 05:51:51 UTC 2021

>15.5.3 says the value of the function result gets its characteristics from the interface

No, it does not say that. It says “the function result” (no “value”) gets its characteristics from the interface.

And “characteristics” are explicitly things possessed by procedures and dummy arguments, and those alone. It is not a synonym for “attributes”. Values do not have “characteristics”.

> I agree that it's not a variable, but it is somehow deallocated after it's used as the expr in an assignment

And you know, weirdly enough, exactly the same thing happens for a function that returns a nonallocatable array. Once the value is not being used, it is deallocated.

We actually spell the allocatable function result case out explicitly in 8.5.3:

“Only variables and components can have the ALLOCATABLE attribute. The result of referencing a function

whose result variable has the ALLOCATABLE attribute is a value that does not itself have the

ALLOCATABLE attribute”

> 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.

It is not a whole array BECAUSE it cannot be subscripted! A whole array can be subscripted (the result of subscripting it is of course not a whole array).

I note that nonallocatable nonpointer array functions also “cannot be subscripted”, and neither can array constructors. We consider none of them to be “whole arrays”.

Of course being subscriptable is not the definition of a whole array, but it is worth noting that every whole array can be subscripted, and many (not all) arrays that are not “whole arrays” cannot be subscripted. So this is not evidence that it is a whole array, but evidence that it is not such.

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

From: Van Snyder <van.snyder at sbcglobal.net <mailto:van.snyder at sbcglobal.net> > 
Sent: Wednesday, December 1, 2021 1:59 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Cc: Malcolm Cohen <malcolm at nag-j.co.jp <mailto:malcolm at nag-j.co.jp> >
Subject: Re: [J3] ALLOCATE with source-expr determining the array bound & resulting lower bound

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 <mailto: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 <mailto:jon.l.steidel at intel.com> >; j3 <j3 at j3-fortran.org <mailto:j3 at j3-fortran.org> >
Cc: Van Snyder <van.snyder at sbcglobal.net <mailto: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 <mailto: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 <mailto:j3 at mailman.j3-fortran.org> >
Cc: Van Snyder <van.snyder at sbcglobal.net <mailto:van.snyder at sbcglobal.net> >; Harald Anlauf <anlauf at gmx.de <mailto:anlauf at gmx.de> >; Chung-Lin Tang <cltang at codesourcery.com <mailto: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 <https://www.nag.co.uk/content/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/20211201/fad8ead0/attachment-0001.htm>