From J.L.Schonfelder@liverpool.ac.uk Thu Feb 24 12:26:17 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA27008 (5.65c8/IDA-1.4.4j for ); Thu, 24 Feb 1994 13:30:41 +0100 Received: from 138.253.31.129 by mailhub.liverpool.ac.uk with SMTP (PP) id <27156-0@mailhub.liverpool.ac.uk>; Thu, 24 Feb 1994 12:26:19 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9402241226.AA26166@uxd.liv.ac.uk> Subject: interpretation 125 (fwd) To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Thu, 24 Feb 1994 12:26:17 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5103 X-Charset: ASCII X-Char-Esc: 29 nagjdc@vax.oxford.ac.uk wrote > Original-Sender: nagjdc@vax.oxford.ac.uk > Date: Wed, 23 Feb 1994 09:33:20 +0000 I am forwarding this with Jeremy's permission. > > Lawrie, I am glad that you have taken up the debate about interpretation 125. > The following comments may lend extra weight to your argument. > > We recently became aware of the issue when we tried to compile our NAG > Fortran 90 library code using the IBM xlf90 compiler. > > There are a number of procedures in our library which have dummy array arguments > with the TARGET attribute, because within the procedure we want to use pointers > to point to them. But we don't want to have to tell users that they must declare > their actual arguments to have the TARGET attribute also. > > Good examples ocur in procedures for solving nonlinear systems of equations or > nonlinear least squares problems. They have optional array arguments which > allow users to receive information about the Jacobian at the solution. The > procedure needs to compute and factorize the Jacobian in any case; the presence > of the optional argument simply determines whether the results are returned > to the calling program or not. > > Therefore we have the used the following kind of template for the code of the > procedures: > > SUBROUTINE nag_nlin_sys_sol( . . . , f_jac, . . . ) > . . . > REAL(wp),INTENT(OUT), OPTIONAL, TARGET :: f_jac(:,:) > . . . > REAL(wp), POINTER :: loc_f_jac > . . . > IF (present(f_jac)) THEN > loc_f_jac => f_jac > ELSE > ALLOCATE(loc_f_jac(m,n)) > END IF > > > > Of course, we could have declared an internal array regardless of the presence > of f_jac, and then copied it to f_jac, if present, immediately before exit, but > it seemed neater to use a pointer, and also less extravagant in use of > memory. > > And because this pattern of coding has worked very satisfactorily with the NAG > compiler we have used it quite widely, although the arguments for using it > rather than some alternative are not always so strong. > > I admit that I haven't attempted to understand all the arguments about the > use of copy-in/copy-out. > > Below I give the report that we sent in to IBM. I had gathered from Malcolm > that we had run up against a contentious issue of interpretation here, but I > intentionally played naive at first. In fact, Janice Shepherd's response was > quite sympathetic: > > "As the committee has not reached consensus on this issue, we had felt it would > be best to be conservative and only allow actual artguments with the TARGET > attribute to be passed to dummy arguments with the TARGET attribute. . . . > We will take NAG's usage of passing non-Target actual arguments to dummy > arguments with the TARGET attribute into consideration. We can reexamine our > position on this issue. Perhaps it is worth while for us to support this as an > extension to Fortran 90." > > Jeremy Du Croz > > --------------------- bug report submitted to IBM ------------------------------ > > We have encountered the following problem using xlf90, version 3.01.0000.0000. > > The problem,is demonstrated by the program below (which has been successfully > compiled and executed using the NAG f90 compiler): > > module mod > contains > subroutine a( n, x ) > ! trivial subroutine to print the first n integers, optionally storing them > ! in the array x > integer, intent(in) :: n > integer, intent(out), optional, target :: x(n) > integer, pointer :: loc_x(:) > if (present(x)) then > loc_x => x > else > allocate( loc_x(n)) > end if > loc_x = (/ (i,i=1,n) /) > write (6,*) 'the first', n,' integers are', loc_x > end subroutine a > end module mod > > program test > use mod > integer :: x(7) > call a( 5 ) > call a( 7, x ) > write (6,*) x > end program test > > Attempting to compile this program results in the following error message: > > ** mod === End of Compilation 1 === > "testibm1.f90", line 23.14: 1513-061 (S) Actual argument attributes do not > match those specified by an accessible explicit interface. > ** test === End of Compilation 2 === > 1501-511 Compilation failed for file testibm1.f90. > > The only difference between the arguments of the actual argument and the > dummy argument is that the dummy argument has the TARGET attribute, while > the actual argument does not. We cannot find anything in the Fortran 90 > Standard which forbids this. Moreover, in the "Fortran 90 Handbook" by > Adams et al., on page 520, there is a diagram which explicitly states that > this combination is allowed (Case D in the diagram). > > Code similar to that illustrated in this example occurs quite frequently > in procedures being developed for the NAG Fortran 90 library; it is a common > way of handling procedures with optional array arguments. > -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk