J3/14-218r1 To: J3 From: Nick Maclaren Subject: ASYNCHRONOUS and argument passing Date: 2014 August 13 ---------------------------------------------------------------------- NUMBER: TBD TITLE: ASYNCHRONOUS and argument passing KEYWORD: ASYNCHRONOUS DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION 1: Is the following program conforming? PROGRAM Main INTEGER, ASYNCHRONOUS :: array(5) = -1 OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read') READ (11, *, ASYNCHRONOUS='yes') array CALL Fred(array(::2)) WAIT (11) PRINT *, array CLOSE(11) CONTAINS SUBROUTINE Fred (arg) ! In general, an external procedure INTEGER :: arg(*) ! Otherwise unused CONTINUE ! In general, something that takes more time END SUBROUTINE Fred END PROGRAM Main QUESTION 2: Is the following program conforming? PROGRAM Main USE ISO_C_BINDING INTERFACE SUBROUTINE Fred (arg) BIND(C) USE ISO_C_BINDING INTEGER(C_INT) :: arg(*) ! Otherwise unused END SUBROUTINE Fred END INTERFACE INTEGER(C_INT), ASYNCHRONOUS :: array(5) = -1 OPEN (11, FILE='junk', ASYNCHRONOUS='yes', ACTION='read') READ (11, *, ASYNCHRONOUS='yes') array CALL Fred(array(::2)) WAIT (11) PRINT *, array CLOSE(11) END PROGRAM Main SUBROUTINE Fred (arg) BIND(C) USE ISO_C_BINDING INTEGER(C_INT) :: arg(*) ! Otherwise unused CONTINUE END SUBROUTINE Fred DISCUSSION: Note that this problem also affects any asynchronous or parallel use, including OpenMP and coarrays. It is not excluded by 5.3.4p2, because 'array' is merely associated with 'arg' in subroutine Fred, and not used in an executable statement or specification expression there. It will obviously not work if the copy-in/copy-out mechanism is used, and the actual I/O transfer occurs while the body of subroutine Fred is being executed. It might seem that this affects only sequence association, but Fortran does not forbid the use of copy-in/copy-out for most ordinary dummy arguments, doing so can sometimes improve performance considerably, and so it is a standard optimisation. Obviously, in the case of question 1, it is a pure pessimisation, but the issue is whether a compiler is required to recognise that case specially. Question 2 is there to indicate that there are circumstances when the copy-in/copy-out needs to be performed by the caller. Again, Fortran does not forbid this from being used for any other calls where that mechanism is needed. The simplest fix would seem to be to add dummy arguments without the ASYNCHRONOUS attribute to the excluded uses. 5.3.4p3 and 9.6.2.5p4 mean that this is unlikely to affect any existing program. ANSWER: None of these program are conforming. Edits are provided to correct the oversight. EDITS: 5.3.4p2 change "executable statement" to "dummy argument without the ASYNCHRONOUS attribute, executable statement". SUBMITTED BY: Nick Maclaren HISTORY: m205 14-nnn Submitted