------- 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
