ENTRY statement
in [Fortran]
|
From: jfh on 23 Sep 2009 00:49 The following program causes a segmentation fault after the first print with every compiler I tried. I presume it is not standard- conforming but I don't understand why. I thought an ENTRY statement was allowed to specify a dummy variable of type a different from the one in the SUBROUTINE statement. program main call findxc(666) end program main subroutine findx (x) implicit none double precision x integer n,ientry ientry = 1 print *,'findx entered at top; x =',x go to 10 entry findxc(n) print *,'findx entered at findxc; n =',n ientry = 2 print *,'ientry =',ientry x = 1.0d0 print *,'x =',x 10 return end subroutine findx Output with g95 (other compilers give similar results): findx entered at findxc; n = 666 ientry = 2 Segmentation fault -- John Harper
From: James Van Buskirk on 23 Sep 2009 01:03 "jfh" <john.harper(a)vuw.ac.nz> wrote in message news:78a1e9f3-16ee-40cc-9dd2-723318a59876(a)f18g2000prf.googlegroups.com... > The following program causes a segmentation fault after the first > print with every compiler I tried. I presume it is not standard- > conforming but I don't understand why. I thought an ENTRY statement > was allowed to specify a dummy variable of type a different from the > one in the SUBROUTINE statement. > program main > call findxc(666) > end program main > subroutine findx (x) > implicit none > double precision x > integer n,ientry > ientry = 1 > print *,'findx entered at top; x =',x > go to 10 > entry findxc(n) > print *,'findx entered at findxc; n =',n > ientry = 2 > print *,'ientry =',ientry > x = 1.0d0 > print *,'x =',x > 10 return > end subroutine findx N1606.pdf, section 12.5.2.4: "If a dummy argument appears in an executable statement, the execution of the executable statement is permitted during the execution of a reference to the function or subroutine only if the dummy argument appears in the dummy argument list of the procedure name referenced." -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: steve on 23 Sep 2009 01:05 On Sep 22, 9:49 pm, jfh <john.har...(a)vuw.ac.nz> wrote: > The following program causes a segmentation fault after the first > print with every compiler I tried. I presume it is not standard- > conforming but I don't understand why. I thought an ENTRY statement > was allowed to specify a dummy variable of type a different from the > one in the SUBROUTINE statement. > > program main > call findxc(666) > end program main > > subroutine findx (x) > implicit none > double precision x > integer n,ientry > ientry = 1 > print *,'findx entered at top; x =',x > go to 10 > entry findxc(n) > print *,'findx entered at findxc; n =',n > ientry = 2 > print *,'ientry =',ientry > x = 1.0d0 > print *,'x =',x > 10 return > end subroutine findx > > Output with g95 (other compilers give similar results): > > findx entered at findxc; n = 666 > ientry = 2 > Segmentation fault > > -- John Harper Well, if I understand F2003 correctly, the code is invalid. If a dummy argument appears in an executable statement, the execution of the executable statement is permitted during the execution of a reference to the function or subroutine only if the dummy argument appears in the dummy argument list of the procedure name referenced. Final Committe Draft, F2003, p 284. -- steve
From: glen herrmannsfeldt on 23 Sep 2009 01:35 jfh <john.harper(a)vuw.ac.nz> wrote: < The following program causes a segmentation fault after the first < print with every compiler I tried. I presume it is not standard- < conforming but I don't understand why. I thought an ENTRY statement < was allowed to specify a dummy variable of type a different from the < one in the SUBROUTINE statement. (snip) < entry findxc(n) < print *,'findx entered at findxc; n =',n < ientry = 2 < print *,'ientry =',ientry < x = 1.0d0 < print *,'x =',x As others have noted, x, being a dummy argument of another entry point, can't be used in the case of a call to findxc. Fortran doesn't specify call by reference, but does allow for it, in which case x can't be referenced in this case. Fortran also allows call by value result (also known as copy-in/copy-out), which could allow assignment to x. Though it seems that, as written, it still wouldn't be legal for OS/360 Fortran, which has ENTRY as a Fortran 66 extension. "Arguments that were received by value at some previous use of the subprogram need not appear in the argument list of the ENTRY statement. Arguments that were received by location much appear." "A dummy argument must not be used in any executable statement in the subprogram unless it has been previously defined as a dummy argument in an ENTRY, SUBROUTINE, or FUNCTION statement." So, to be legal in for OS/360, there would have had to have been a call to the main entry point before x was used. When ENTRY was added to Fortran 77 this feature was not included. -- glen
From: Richard Maine on 23 Sep 2009 01:41
jfh <john.harper(a)vuw.ac.nz> wrote: > The following program causes a segmentation fault after the first > print with every compiler I tried. I presume it is not standard- > conforming but I don't understand why. I thought an ENTRY statement > was allowed to specify a dummy variable of type a different from the > one in the SUBROUTINE statement. > > program main > call findxc(666) > end program main > > subroutine findx (x) > implicit none > double precision x > integer n,ientry > ientry = 1 > print *,'findx entered at top; x =',x > go to 10 > entry findxc(n) > print *,'findx entered at findxc; n =',n > ientry = 2 > print *,'ientry =',ientry > x = 1.0d0 > print *,'x =',x > 10 return > end subroutine findx It has nothing to do with the types. It has to do with trying to do things with the dummy argument x in an entry where x is not one of the dummy arguments. That's not allowed, as noted by the other responders. I'm slightly puzzled as to what you would expect this to do. There used to be a nonstandard f66 form of entry that allowed you to use dummy arguments from prior calls, somewhat as though they were somehow saved. I've seen multiple posts from people expecting that behavior, or perhaps trying to work with old nonstandard code that expected it. If I restricted myself only to the subroutine here, I might think that was what was expected. But there isn't a prior call to findx, so this wouldn't be valid even with that old extension. The only thing I can think is that perhaps you are under the impression that this is an obscure way to equivalence x and n. It isn't. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |