(j3.2006) a question on cobounds

[Bill Long]

Malcolm Cohen wrote:
> 
> Bill Long wrote:
>> Jim Xia wrote:
>>   
>>> For the following declarations
>>>
>>> subroutine foo (n)
>>>         integer, intent(in) :: n
>>>         integer W(n)[*]                           !<-- we made it clear
>>> this is not allowed
>>>     
>> Right. Automatic coarrays are not allowed.
>>
>>   
>>> *        integer, save :: U(10)[N,*]      !<-- but do we intend to allow
>>> this?  I have difficulties in finding constraints/rules that forbid this*
>>>
>

> C529 says
>    "(R511) A <lower-cobound> or <upper-cobound> that is not a constant 
> expression shall appear only in a subprogram, derived type definition, 
> or interface body."
> 
> My followup question is: how can a cobound appear in a derived type 
> definition?  

A coarray component has to be allocatable and the declaration for an 
allocatable coarray does not contain cobounds, so a cobound would not 
appear in a derived type definition.  The ", derived type definition," 
should be deleted from C529.


> 
> My followup question 2 relates to the text you quoted, which says
>    "If an explicit-coshape coarray has cobounds that are not constant 
> expressions, the cobounds are determined at entry to the procedure ...".
> Well, if the definition appears in an interface body or derived type 
> definition, those are not procedures.  Therefore explicit-coshape 
> coarrays are not allowed in interface bodies or derived type definitions 
> (seeing as how the standard just got an internal error).  That would 
> seem to be a problem for nonallocatable dummy coarrays.


I don't understand the argument regarding interfaces.  If the interface 
body and the corresponding subroutine definition are to match and you 
allow non-constant cobounds one place, they have to be allowed in the 
other as well.  This parallels the case of an explicit-shape array in a 
subroutine that has bounds specified by variables.  Certainly a 
declaration like this is allowed in an interface body.


> 
> My followup question 3 relates to the BLOCK construct; viz, this is not 
> integrated into it.  The quoted text says that in
>    SUBROUTINE s(n) ! Suppose N is equal to 100 on entry.
>    ...
>    n = 10
>    BLOCK
>      REAL,SAVE :: cob[n:*]
>      cob[n] = 3 ! PROBLEM
> 

Indeed, BLOCK constructs allow local variable declarations just like 
subroutines do. This needs to be fixed.

Cheers,
Bill




-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120