[J3] Vector subscripts and INTENT(INOUT)

Malcolm Cohen malcolm at nag-j.co.jp
Thu May 10 21:48:35 EDT 2018


> This pretty flatly says the CALL is not conforming,

 

Yes…

 

> and says directly that any array section with a vector subscript is not definable. 



No it does not.  Read it again: it says the *dummy* is not definable.  A dummy argument is not any kind of array section, let alone one with a vector subscript – it is a whole array.  This has no bearing whatsoever on whether an array section with a vector subscript is definable.

 

>Since the rules for INTENT(INOUT) (8.5.10 p4)
>
>• The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument that corresponds to the dummy argument shall be definable.
>
>hinge on whether the actual argument is definable

 

No they don’t.  This is what it specifies.  However, there are other requirements that interact with INTENT(INOUT), one of which you have found.

 

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

 

As Van mentioned, the performance implications of treating dummies associated with vector-subscripted array section actual arguments as definable are severe.  Well, passing the vector-subscripted array is (generally) going to result in copy-in, which is bad enough, but we definitely Do Not Want to impose a copy-out as well.  The way to avoid the copy-out is precisely what we have done: declare the dummy to be non-definable.

 

In the unlikely event of the user actually wanting to update a vector-subscripted object via a nonelemental procedure call, he can manually do the copy-in/out with an explicit temp himself; so there is no loss in actual functionality, it’s just a tradeoff of convenience (in the unusual case) vs. performance (in the usual case).

 

I note that the text in 8.5.10 is already considerably duplicative of text elsewhere.  As is, although duplicative it is “ok”, as it is explaining the semantics.  Making it more duplicative by copy extra rules would be a step in the wrong direction.

 

Cheers,

-- 

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

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Bill Long via J3
Sent: Friday, May 11, 2018 7:46 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Bill Long <longb at cray.com>
Subject: [J3] Vector subscripts and INTENT(INOUT)

 

Consider this example code:

program test_vector
implicit none
integer :: iv(5) = [1,3,5,7,9]
integer :: dat(10) = 0

call sub (dat(iv))
print *, dat

contains

subroutine sub (array)
integer,intent(inout) :: array(:)

array = 1
end subroutine sub


Multiple compilers reject this code based on this requirement in Clause 15:


15.5.2.4 p19

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

This pretty flatly says the CALL is not conforming, and says directly that any array section with a vector subscript is not definable. 


However, we have in 9.5.3.3.2:

" • If a vector subscript has two or more elements with the same value, an array section with that vector subscript
is not definable and shall not be defined or become undefined.”

which is more limited, and suggests that a vector subscript that does NOT have repeated values produces an array section that COULD BE definable, 


Since the rules for INTENT(INOUT) (8.5.10 p4)

• The INTENT (INOUT) attribute for a nonpointer dummy argument specifies that any actual argument that corresponds to the dummy argument shall be definable.

hinge on whether the actual argument is definable, there seems to be an inconsistency.


So: Is an array section with a vector subscript that has no repeated values definable? If not, why does the limitation in 9.5.3.3.2 have the qualification on ‘same value’?

Cheers,
Bill


Bill Long longb at cray.com <mailto: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



Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

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/20180511/3cf70214/attachment.html>


More information about the J3 mailing list