[J3] Vector subscripts and INTENT(INOUT)

Bill Long longb at cray.com
Mon May 14 18:10:03 EDT 2018


> On May 11, 2018, at 9:28 PM, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
>> On May 11, 2018, at 1:15 PM, Bill Long via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>>>> Is an array section with a vector subscript that has no repeated values definable?
>>> 
>>> Only if the base array is definable (not always the case!).  This is perfectly straightforward – a vector-subscripted array variable is itself a variable, and therefore definable unless there is a rule otherwise, which there is not.
>> 
>> So, if I remove the INTENT(INOUT) from the example code  [hence no INTENT specified], then the code should be conforming.  Although trying that version, which does compile, results in all zero values being printed, as if the subroutine was not executed. I.e. copy-in, but no copy-out.  That is the case for multiple compilers.
> 
> The code is not conforming, even without the INTENT.  The text from paragraph 19 of 15.5.2.4, which you cited in the first message of this thread, says that the variable is not definable.  The text that follows the phrase "the dummy argument is not definable" does not make the dummy argument definable.


I see that, but am concerned that none of the 4 compilers I tried on this code issued any message.  And all appeared to do what was the underlying intention of the design - to allow copy-in, but not do the copy-out.   Perhaps the lack of a message was due to the way this is stated.  The current test says ‘the dummy argument is not definable’ as if it were a statement of fact, rather than a requirement, as in ‘the dummy argument shall not be defined’.  Messages are typically for requirement violations. 

The same subclause, in Paragraph 6, has another case where we effectively have copy-in but no copy-out, and for mainly similar reasons.  That is written as a “shall” requirement and would certainly have resulted in an error message.   It might be clearer to move the array subscript there, so that these cases are covered on one place.  Making p6 read:

"	• If the actual argument is a coindexed object with an allocatable ultimate component or an array section with a vector subscript, the dummy argument shall have the INTENT (IN) or the VALUE attribute.”

This avoids any question about the case of no INTENT specified, or whether the actual argument is definable.   Furthermore, Paragraph 19 can be substantially simplified from 

“ 	• If the procedure is nonelemental, the dummy argument does not have the VALUE attribute, and the actual argument is an array section having a vector subscript, the dummy argument is not definable and shall not have the ASYNCHRONOUS, INTENT (OUT), INTENT (INOUT), or VOLATILE attributes.”

to become

"	• If the procedure is nonelemental, the dummy argument does not have the VALUE attribute, and the actual argument is an array section having a vector subscript, the dummy argument shall not have the ASYNCHRONOUS or VOLATILE attributes.”

since the INTENT(OUT) and INTENT(INOUT), as well as definition of the dummy, are prohibited by the INTENT(IN) requirement. 

Issues raised:

1) The change in p6 is a technical one - new requirement of INTENT(IN) or VALUE for the dummy, and hence is better as a proposal for 202X.  We are late in the 2018 process to be making technical changes.  [Although I think this is a definite improvement, as technical changes go.]

2) It is not clear why ASYNCHRONOUS is prohibited in P19.  The dummy could reasonably be allowed in an asynchronous WRITE statement within the subprogram, as long as the corresponding WAIT statement was executed later in the same subprogram.  But this appears to be prohibited. 

3) Note 15.21 following p6 ends with the sentence "If necessary, on return from the procedure, the value of the copy would be copied back to the actual argument.”   You never do a copy-out for a VALUE argument, and it seems pointless to do a copy-out of an INTENT(IN) argument since it never changed value.  So I don’t see a case where this would be “necessary”. 

Cheers,
Bill





> 
> Robert Corbett

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425




More information about the J3 mailing list