array section as actual argument where dummy argument is INTENT(OUT) 
Author Message
 array section as actual argument where dummy argument is INTENT(OUT)

I understand that an array becomes undefined the moment it is passed to
a subroutine, if the respective dummy argument is INTENT(OUT). So if the
subroutine doesn't assign values to the whole array, the rest of the
array remains undefined. And then, as I read in a posting by Richard
Maine, the whole array is undefined because

 > In 14.7.1 we find "An object is defined if and only if all of its
 > subobjects are defined."

But what about the following example, where only an array section is
passed to a subroutine:

MODULE mo_fill
   !
CONTAINS
   !
SUBROUTINE se_fill(k)
   IMPLICIT NONE
   INTEGER,INTENT(OUT) :: k(:,:)
   k = 3
END SUBROUTINE se_fill
   !
END MODULE mo_fill
   !
PROGRAM pr_section
   USE mo_fill ,ONLY : se_fill
   IMPLICIT NONE
   INTEGER :: ji
   INTEGER :: jj
   INTEGER :: k(1:2,1:2)
   !
   k = 0
   CALL se_fill(k(1:1,1:1))
   DO ji = 1,2
      DO jj = 1,2
         PRINT *,jj,ji,k(jj,ji)
      ENDDO
   ENDDO
END PROGRAM pr_section

I would assume that on entry to se_fill, INTENT(OUT) deletes the
definition of the array elements which are actually passed. Since the
information is fully restored within the subroutine, the temporary loss
of definition shouldn't do any harm outside se_fill.

When compiled with the Fujitsu fortran Compiler Driver Version 5.1.1 and
option -Eg, the program output reads:

  1 1 3
jwe0323i-w line 24 The variable (k(2,1)) has an undefined value.
  error occurs at MAIN__   line 24 loc 00010c58 offset 000002c4
  MAIN__       at loc 00010994 called from o.s.
taken to (standard) corrective action, execution continuing.
  2 1 -1953789045
  1 2 0
  2 2 0

Is this a bug in the program or a bug of the compiler?
Does the f95 standard really want me to either in se_fill declare k
INTENT(INOUT) or do an explicit copy of the array section in the calling
procedure, like

   INTEGER :: k(1:2,1:2)
   INTEGER :: ksection(1:1,1:1)
   !
   k = 0
   CALL se_fill(ksection(1:1,1:1))
   k(1:1,1:1) = ksection

---
Alfred Trukenmller
MI, Universit?t Hamburg
Hamburg, Germany



Fri, 19 May 2006 21:47:01 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)
Looks OK to me. Seems like a bug in the checking functionality of the
compiler. Works perfectly well with CVF 6.6B, for instance.

        Jan



Fri, 19 May 2006 22:40:52 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)
Hi Alfred

To use automatic array in subroutine or function, it must be declared with
INTENT(INOUT) when the array is modified in the sub-program : the compiler
must find the correct dimension of this array at the call.

Best regards

Pascal.



Quote:
> I understand that an array becomes undefined the moment it is passed to
> a subroutine, if the respective dummy argument is INTENT(OUT). So if the
> subroutine doesn't assign values to the whole array, the rest of the
> array remains undefined. And then, as I read in a posting by Richard
> Maine, the whole array is undefined because

>  > In 14.7.1 we find "An object is defined if and only if all of its
>  > subobjects are defined."

> But what about the following example, where only an array section is
> passed to a subroutine:

> MODULE mo_fill
>    !
> CONTAINS
>    !
> SUBROUTINE se_fill(k)
>    IMPLICIT NONE
>    INTEGER,INTENT(OUT) :: k(:,:)
>    k = 3
> END SUBROUTINE se_fill
>    !
> END MODULE mo_fill
>    !
> PROGRAM pr_section
>    USE mo_fill ,ONLY : se_fill
>    IMPLICIT NONE
>    INTEGER :: ji
>    INTEGER :: jj
>    INTEGER :: k(1:2,1:2)
>    !
>    k = 0
>    CALL se_fill(k(1:1,1:1))
>    DO ji = 1,2
>       DO jj = 1,2
>          PRINT *,jj,ji,k(jj,ji)
>       ENDDO
>    ENDDO
> END PROGRAM pr_section

> I would assume that on entry to se_fill, INTENT(OUT) deletes the
> definition of the array elements which are actually passed. Since the
> information is fully restored within the subroutine, the temporary loss
> of definition shouldn't do any harm outside se_fill.

> When compiled with the Fujitsu Fortran Compiler Driver Version 5.1.1 and
> option -Eg, the program output reads:

>   1 1 3
> jwe0323i-w line 24 The variable (k(2,1)) has an undefined value.
>   error occurs at MAIN__   line 24 loc 00010c58 offset 000002c4
>   MAIN__       at loc 00010994 called from o.s.
> taken to (standard) corrective action, execution continuing.
>   2 1 -1953789045
>   1 2 0
>   2 2 0

> Is this a bug in the program or a bug of the compiler?
> Does the f95 standard really want me to either in se_fill declare k
> INTENT(INOUT) or do an explicit copy of the array section in the calling
> procedure, like

>    INTEGER :: k(1:2,1:2)
>    INTEGER :: ksection(1:1,1:1)
>    !
>    k = 0
>    CALL se_fill(ksection(1:1,1:1))
>    k(1:1,1:1) = ksection

> ---
> Alfred Trukenmller
> MI, Universit?t Hamburg
> Hamburg, Germany



Sat, 20 May 2006 22:47:46 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)

Quote:
> To use automatic array in subroutine or function, it must be declared with
> INTENT(INOUT) when the array is modified in the sub-program : the compiler
> must find the correct dimension of this array at the call.

Nope - the metadata aka shape of the array is not covered by the INTENT
statement; this point was discussed only recently.

        Jan



Sat, 20 May 2006 23:27:02 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)


Quote:
> Hi Alfred

> To use automatic array in subroutine or function, it must be declared with
> INTENT(INOUT) when the array is modified in the sub-program : the compiler
> must find the correct dimension of this array at the call.

The array used in the example is an assumed-size array. The shape
information is available because the use of an assumed-size array requires
an explicit interface, as correctly shown in the example. An automatic array
is local to a procedure and cannot be a dummy argument. In short, the posted
example is entirely correct.

Regards,

Mike Metcalf



Sun, 21 May 2006 00:06:07 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)

Quote:
> The array used in the example is an assumed-size array.

Whoops, assumed-SHAPE.


Sun, 21 May 2006 00:25:24 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)

Quote:
> Is this a bug in the program or a bug of the compiler?

  This looks like a bug in an older version of the compiler. I tried
your code with LF95 v5.7 using the -chk, -chkglobal and -Eg options,
and always got these results:

1 1 3
2 1 0
1 2 0
2 2 0

Best regards,

Tim Zeisloft
Lahey Computer Systems, Inc



Sun, 21 May 2006 02:21:36 GMT  
 array section as actual argument where dummy argument is INTENT(OUT)

Quote:

>   This looks like a bug in an older version of the compiler. I tried
> your code with LF95 v5.7 using the -chk, -chkglobal and -Eg options,
> and always got these results:

> 1 1 3
> 2 1 0
> 1 2 0
> 2 2 0

Thanks a lot for all comments. Encouraged by Tim's reply, I have
downloaded the trial version of lf95 v6.20c for Linux which also (unlike
the older v6.00c) doesn't diagnose an undefined value.

Kind regards,

Alfred Trukenmller
MI, University of Hamburg



Sun, 21 May 2006 21:30:51 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Actual argument is incompatible with dummy argument

2. Intel error: type of actual argument differs from type of dummy argument

3. Actual Argument & Dummy Argument question

4. Overlapping array sections as actual arguments?

5. Dummy argument INTENT() attribute question.

6. arguments/dummy arguments

7. Procedures as arguments - set dummy arguments

8. overlap of INTENT(IN) and INTENT(OUT) arguments

9. Allow ELEMENTAL procedures with INTENT(IN) array arguments?

10. f90/95: definition status of actual arg with intent(out) dummy

11. Arguments, dummies, and working arrays

12. how to define a dummy argument derived-Type array?thanks

 

 
Powered by phpBB® Forum Software