[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- 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 -, 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
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-11 19:54 --- (In reply to comment #3) > I fully agree that the second "deallocate (p2, stat=ios)" is a violation. > That is the actual intend of this program. Well, I can also complain that fhjdshlkgjflsg end does not calculate PI - but why should it? If a program is invalid, everything can happen! > 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. Like most Fortran compilers, gfortran does not track the allocation. It simply checks: Is the pointer a NULL pointer, if not - free it. Then, the C library tells the operating system that the memory is no longer needed. If you know access the memory (reading or writing), the operating system has to stop you from doing so. (Otherwise, you could widely modify the memory belonging to other users.) And it does so by killing your program. Sometimes, also the C library does some checking by keeping track of which variables are allocated or not. But gfortran does not add another layer on top of it to keep track of all allocated variables. That is simply to expensive (computationally but also in implementing it). Thus, if you do something invalid of this kind, the program will be killed > For example, I read in Stephan J. Chapman "Fortran 90/95 for scientists and > engineers", p 635 "If the pointer in the statement happens to point to a > target not created with an ALLOCATE statement, then the DEALLOCATE statement > fails and the program aborts UNLESS THE STAT= CLAUSE WAS SPECIFIED" > (emphasis is mine). Well, but that's a different case: The pointer is in a well-defined state (namely it is associated). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- 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)" 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. For example, I read in Stephan J. Chapman "Fortran 90/95 for scientists and engineers", p 635 "If the pointer in the statement happens to point to a target not created with an ALLOCATE statement, then the DEALLOCATE statement fails and the program aborts UNLESS THE STAT= CLAUSE WAS SPECIFIED" (emphasis is mine). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #2 from kargl at gcc dot gnu dot org 2010-06-11 18:12 --- Reset several to 'normal'. Fortran bugs are never 'major'. I believe your code is invalid, and so gfortran can do anything it wants. F2003 has 19 6.3.3.2 Deallocation of pointer targets If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, the pointer shall not be deallocated. If a pointer appears in a DEALLOCATE statement, it shall be associated with the whole of an object that was created by allocation. Deallocating a pointer target causes the pointer association status of any other pointer that is associated with the target or a portion of the target to become undefined. Your statement "deallocate (p1, stat=ios)" causes p2 to become undefined. Thus, your statement "deallocate (p2, stat=ios)" violates the first sentence in this section. Of course, I could be wrong. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-11 18:04 ---
I think this is a bug in your program:
allocate (a) ! Allocate memory
p1 => a
p2 => a
! All of {a, p1, p2} point to the same memory.
deallocate (p1, stat=ios)
! Free memory pointed to by {a, p1, p2}
! and mark "p1" as disassociated / not-allocated
!
! p2 and a have the pointer-association status "undefined"
deallocate (p2, stat=ios)
! Invalid: Access to pointer with "undefined" pointer association status.
Or to put into standard speech: http://gcc.gnu.org/wiki/GFortranStandards
"A pointer may have a pointer association status of associated, disassociated,
or undefined. Its association status may change during execution of a program.
Unless a pointer is initialized (explicitly or by default), it has an initial
association status of undefined. A pointer may be initialized to have an
association status of disassociated or associated."
"16.5.2.5 Events that cause the association status of pointers to become
undefined":
"(3) the target of the pointer is deallocated other than through the pointer,"
And finally:
"A pointer that is not associated shall not be referenced or defined."
and
"If a pointer appears in a DEALLOCATE statement, its association status shall
be defined."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
