(j3.2006) Disassociated array pointer actual argument corresponding to an optional argument of elemental procedure.

Daniel C Chen cdchen
Tue Dec 9 11:00:24 EST 2014

I agree with Malcolm and Van that we need some fix that is similar to item
(6). However, I am not sure if fixing (6) only is a good idea as the header
paragraph begins with "An optional dummy argument that is not present is
subject to the following restrictions." and some of the sibling items to
(6) are specifically for dummy argument.

As for the example reason that we prohibit the item (6) case as given by
Malcolm, is the rank of a pointer or allocatable array always known at the
compile time regardless the association status? The shape is the one that
is undefined when the pointer is disassociated but is used for
scalarization in this case. However, shape is a characteristics only if it
is not a pointer or an allocatable (12.3.3).



XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com

From:	"Malcolm Cohen" <malcolm at nag-j.co.jp>
To:	"fortran standards email list for J3"
            <j3 at mailman.j3-fortran.org>
Date:	12/08/2014 20:06
Subject:	Re: (j3.2006) Disassociated array pointer actual argument
            corresponding to an optional argument of elemental procedure.
Sent by:	j3-bounces at mailman.j3-fortran.org

Hi Daniel,

>Is the following program standard conforming?
>      integer, pointer :: p1(:)
>      integer k
>      nullify(p1)
>      call sub1(p1, k)
>      contains
>      impure elemental subroutine sub1(arg1, arg2)
>        integer,  intent(inout), optional :: arg1
>        integer,  intent(in) :: arg2
>      end subroutine
>      End
>P1 is disassociated, but its extent is used to scalarize the elemental
>procedure call. Is this code standard conforming?

No interpretation is established, so no.

>The only thing I found that is sort of relevant in the standard is
>p3: (6)]
>"An optional dummy argument that is not present is subject to the
>(6) If it is an array, it shall not be supplied as an actual argument
> to an elemental procedure unless an array of the same rank is
> supplied as an actual argument corresponding to a nonoptional
> dummy argument of that elemental procedure."
>Do we need something similar to this for the test case at the above?

I think we do.  It is clear that we did not intend to allow this.

Van suggests:
>I don't think we need something extra for this case, but item (6) ought to

Rewording item (6) might well be the best way to fix it, but I do think it
to be fixed rather than relying on a combination of "obvious intent" and
fact that allowing it does not make sense.

Bill suggests:
>The call should have the same effect as
>   call sub1 (arg2 = k)
>which is valid and results in a scalar call, since all of the actual
>are scalar.

This is completely without merit, since whether P1 is declared
or "INTEGER,OPTIONAL" makes no difference to the way that optionality
I.e. that argument applies precisely to the exact case that item (6)

We prohibit that case for good reason, and one of those good reasons is
allowing it would make it trivial to construct a generic reference that
not be resolved at compile-time (because the rank of a function reference
depend on whether a pointer was associated).  Thus violating one of the
fundamental principles of generic resolution.

................................Malcolm Cohen, Nihon NAG, Tokyo.

J3 mailing list
J3 at mailman.j3-fortran.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20141209/336a8c91/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20141209/336a8c91/attachment-0001.gif 

More information about the J3 mailing list