------- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2010-06-11 20:16 ------- Subject: Re: DEALLOCATE aborts program even with STAT=
On Fri, Jun 11, 2010 at 06:22:57PM -0000, remko dot scharroo at me dot com wrote: > > > ------- Comment #3 from remko dot scharroo at me dot com 2010-06-11 18:22 > ------- > I fully agree that the second "deallocate (p2, stat=ios)" is a violation. > That is the actual intend of this program. > You know, this is not arbitrary code. You can often have multiple pointers > pointing to allocated memory, and then you want to deallocate the memory. > Then you need to do multiple "deallocate" statements. > You cannot do it any other way, since you cannot test "if (allocated)" since > the pointer is not "allocatable". > Therefore, the best try is to simply deallocate all the pointers, i.e., > "deallocate (p2, stat=ios)" You deallocate the memory once and nullify the pointers. program deallocate_test integer, pointer :: p1,p2,a integer :: ios allocate (a) p1 => a p2 => a print *, associated(a), associated(p1), associated(p2) deallocate (a, stat=ios) p1 => null() p2 => null() print *, associated(a), associated(p1), associated(p2) end program deallocate_test The text from the F2003 standard that I quoted is neither a constraint or restriction on the fortran processor. It is a prohibition on the programmer. I don't have any other F2003 compiler available to me. What happens if you compile your code with other compilers? > Reading your excerpt from the F2003 standards, it does, of course, shows the > violation. But then I expect ios simply to be non-zero, not get an abort. That's an unrealistic expectation. You've violated the standard, which allows a compiler to anything (including what you expect). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
